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

[Florian Lindner]

Philipp von Weitershausen schrieb:
> 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!

The Main object should contain anything which does not fit elsewhere. It 
should also contain the index page of the entire site. It should be the 
central point which manages all the other objects, provide the glue for 
all the other objects.

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

I'm not comming from Zope 2 rather from traditional non-web OOP 
programming (C++). I've used Zope2 but only a litte bit TTW.

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

My schema for CS.Event (CS/Event/interfaces.py):

class IEvent(Interface):
     """This interface stores information about a event."""

     def __setitem__(name, object):
         """Add a IEvent object."""

     name = TextLine(
         title = u"Name",
         description = u"Short name",
         # default = u"",
         required = True)

     location = Text (
         title = u"Location",
         description = u"The location where the event take place.",
         default = u"",
         required = False)

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

Aren't content types automatically persistent? (my defination of 
persistent is that they keep the content savend in the ZODP)

I've this class which implements the interface from above:

class Event(Contained):
     __doc__ = IEvent.__doc__

     implements(IEvent, IEventContained)

     # See CS.Event.interfaces.IEvent
     description = None

     # See CS.Event.interfaces.IEvent
     location = None

     # See CS.Event.interfaces.IEvent
     name = None


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

Ok, that's clear.


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

Sure.

>> 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).

Ok, the knowledge of the presentation mode is contained in views. A 
addfrom is a view, too, isn't it?

> 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.

The good old times...

> 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?).

You give the car object a refeence to an instance of another radio 
object. But don't want to argue here...  ;-)

> 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.

So I try to register a addform for the centershock layer:

<addform
   for="..interfaces.IEvent"
   name="addEvent.html"
   permission="zope.Public"
   schema="..interfaces.IEventFolder"
   content_factory="..event.Event"
   layer="centershock" />


>> 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.

I still don't understand how to customize the addform. I think if you 
would give some examples this would greatly help me.

[...]

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

I am! But what I want to know it either not described in the book or I 
don't find it.

I know that I've still problems getting the great picture but I really 
hope this would get better when I've finished some minor projects.
I really appreciate your explanations of the concepts but I would really 
like if you would give some examples. If you want I can also send my 
entire project to you, it's less than 20KB.
Thanks,
Florian