R: [Zope] Discussion: Best practice site struture (LONG)

[Max M]

Paul Winkler wrote:

>Hi Max, this is a VERY interesting thread to me now,
>very timely.
>

Great!

>A very rough and ugly mockup is at
>http://www.slinkp.com/linux/soundapp_site_roughs/app_entry.html
>Obviously that site has a specific audience in mind,
>but I'd like my product to be generally useful too.
>

Sound and music ... one of my most favourite topics :-)

>>relations in it's own folder like::
>>
>>    students/
>>        Johnny
>>        Mary
>>        Adam
>>        Eve
>>    Math
>>        students/Johnny
>>        students/Mary
>>    Science
>>        students/Adam
>>        students/Eve
>>    History
>>        students/Adam
>>        students/Eve
>>        students/Johnny
>>        students/Mary
>>
>
>Yes, I thought of doing something like this...
>But in this approach, I was unclear on how the relationships are implemented 
>Perhaps in your example History is just an object with a "students" 
>property that is simply a list of the ids of Student objects from
>the Students folder?
>

That isn'r really important at this stage. Just the idea of relating to 
objects.

>>And then you would have another structure creating the view of the site, 
>>which could be like this::
>>
>>    Home
>>        allClasses
>>            Math
>>                Johnny
>>                Mary
>>
>snip...
>
>So how does Math get its list of students?
>By asking Relations/Classes/Math what students it contains?
>

Yes

>Now about managing the relations...
>Can you talk me through an example? What happens if e.g.
>Johnny drops out of Math?
>
>Or if Johnny drops out of school?
>
>Or if Math is cancelled permanently?
>
>etc...
>

The problem with that is that it really is application specific. You 
cannot handle these cases generally. There is no way of knowing the 
right way to act if an object is deleted. It depends on the type of 
object, it's relations and the application. Sometimes it's also a 
question of business process. Some company might have added an extension 
that needs a copy of the object to stay around so it isn't really delete 
but just marked as inactive. Other companies might just delete those 
objects. etc.

You should use "manage_beforeDelete()" to handle these cases. It is 
called by Zope before an object is deleted if the object has the method 
implemented.

>I can see that this helps cohesion and reduces coupling,
>because all the relationships are managed by Relations
>and nothing else even knows about them. That's good.
>And fewer methods need to be added to create a new
>relationship.
>

Exactly

>>Btw. Zope's power is certainly in the ZODB. You just have to use it in a 
>>more disciplined manner than you first get the impression of.
>>
>
>So you'd recommend against using SQL?
>I've yet to really tackle the SQL beast, ZODB has been fine
>for my web projects so far...
>

I would certainly not recommend against using SQL, but even thought I am 
an experienced user of SQL I hardly ever use it in Zope. The 
object/relational impedance mismatch is simply to annoying ;-) But it 
has probably also something to do with the type of apps I write.

regards Max M