[Zope3-dev] Re: How to add objects?

[Philipp von Weitershausen]

Florian Lindner wrote:
> Hello,
> I've asked this question already about two weeks ago but I think that I 
> explained it in a bad way to noone understood it...
> 
> I've two content componenents: Event and Main.
> 
> Main is responsible for anything which is not related to a Event, like 
> navigation bar, display welcome or aboutus pages. There should be a link 
> from a site contained in Main to a form in which you fill in the 
> information needed to create a new Event (Location, Time, Description). 
> After submitting this form the new Event should be created and one 
> should be redirected to a confirmation page.

This "Main" content type doesn't sound like a content type at all... 
What kind of content does it store? Text? Navigation bar? Links? The 
latter two are not content!

Free yourself from the cluttered Zope 2 understanding of persistent 
objects. Try to *really* divide things into their responsiblities:

- what kind of data do I need to store? -> write a schema

- how do I want to store that data? -> write a content component (this 
is usually a *very* simple class that only inherits from Persistent!)

- how do I want to present that data? -> write views

Navigation bars, etc. are clearly the responsiblity of views.

> As far as my understanding of OOP goes it is Events responsibility to 
> provide such a form and handle the creation of the object (since I've 
> defined a factory in the registration of Event, now I need a "visual 
> factory").

Nope. Your "Event" is just a content component. It knows nothing 
(repeat, nothing) about how it is presented, how the user provides its 
data etc. It just stores the data (see above).


Your understanding of OOP is what I call "conservative". Back when OOP 
became popular, OOP was often explained like this:

   - You have an object, e.g. a car

   - That object can tell you stuff about itself, e.g. its horse power

   - The object can _do_ stuff, either to itself or to other objects,
     e.g. transport people and goods.

This concept was misinterpreted in a way that objects had to provide all 
of the functionality that was related to them (e.g. cars also have to 
know how to play music for the passengers).  A popular way of combining 
many different functionalities in one instance was subclassing.  This 
led to bloated and very inflexible objects (e.g. what if you wanted to 
change the music device inside the car?).

Zope 3's Component Architecture divides responsibilities into different 
components. Every component does its own thing. If it needs to do more, 
it asks another component to do it for it. Thus, instead of having the 
car play music, you'd install a car radio that would do it instead. That 
way you could also install a better one when you want.

> Of course, I've a already defined a addform, but this is only for the ZMI:
> 
>     <addform
>         label="Add CSEvent"
>         name="AddCSEvent.html"
>         schema="..interfaces.IEvent"
>         content_factory="..event.Event"
>         permission="zope.ManageContent"
>     />

In Zope 2, "only for the ZMI" would be correct.  In Zope 3, the line 
between the ZMI and a custom user interface has been blurred. Stuff that 
you define for the ZMI can largely be reused in a custom user interface. 
I other words, the ZMI in Zope 3 is just *one* user interface. Take it, 
customize it, and voila, you have your own user interface.

> But I want to design the form myself using my own skin.

There's nothing that prevents you from doing that. Views are by default 
registered for the "default" layer, a layer that should be available for 
all skins. Thus, in your custom skin the very same add form can look 
very different, just like all other views can look very different.  In 
short, the add form produces HTML which shouldn't determine the layout 
of the page.

If you want to shuffle the order of the input fields, use the fields="" 
parameter of the <addform> directive.

> My questions are:
> 
> a) How to I configure such a add form?

You already did so (the above addform directive). Your assumption that 
this only works in the "ZMI" is incorrect. It works in any user 
interface (=skin) that you create and that is based on the 'default' layer.

> b) How do the form need to look like? Like names for the input fields, 
> destination to post form data, ...

Zope renders that from the schema. You shouldn't need to worry about this.

> c) If the form needs a supporting view class, how do the class has to 
> look like?

Most of the time you don't need a class that supports the view unless 
you want to do some very customized stuff.

> d) How do I call the form?

some_folder/+/?type_name=<factory_id_or_addform_name>

if I remember correctly.

> Thanks a lot for answering all or some question, for pointing me to 
> documentation or if I get something completely wrong for putting me back 
> on the right path!

I strongly recommend reading over Stephan's book again or buy a copy of 
by book when it's out (January-ish).

Philipp