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

Max M maxm@mxm.dk
Fri, 05 Apr 2002 21:56:28 +0200


Zanotti Michele wrote:

 >Your mail is very interesting for me

Thanks

 >but I think I have missed something (I
 >don't have experience with big sites and I'm reading your -i think- 
minimal
 >product howto... so excuse me if I am trivial). In my opinion in Zope
 >approach the structure of the site isn't so important, objects have
 >properties and properties permit several (logical) views of the site and
 >this is Zope's strength.

Yes certainly, this is the Model View Controller line of thinking.

 >For example (I'm only trying to explain my point of
 >view), a teacher's document can have an author-name property, an 
author-role
 >property, a course property, a topic property..., so it isn't important if
 >the teacher changes school or work...

How does the property get updated on the document then? What if his 
folder is deleted? What if the new teacher need to edit the document? To 
name but a few problems.

 >(For several months I have used Zope
 >only because it makes rapid to do simple work with rdbms, but now I think
 >that Zope power is in ZODB). So I think Zope changes the problem from 
'site
 >structure' to 'find correct properties'. Can you tell me where I'm wrong?


I think I unserstand your question. I can try to illustrate it with a 
simple many/many relation example.

------

I have no idea how the american school system is structured, but let's 
pretend that there is a school with 4 student that starts in 2002.

Adam
Eve
Johnny
Mary

They attend different classes.

Math
Science
History

So the class list is a like this::

Math
    Johnny
    Mary
Science
    Adam
    Eve
History
    Adam
    Eve
    Johnny
    Mary

Here they are stored several times. That is bad. What if Johnny changes 
his address? Then it must be chenged in several places. This is 
redundancy, and I guess you know about that when you have worked with 
relational databases.

So where do we put the students. Your approach seems to be that you want 
to store the student in one place only, perhaps like this, in the first 
class they start in::

    Math
        Johnny
        Mary
    Science
        Adam
        Eve

And then the history class could just link via a property to the 
students allready in the other classes.

    History
        Science/Adam
        Science/Eve
        Math/Johnny
        Math/Mary
        
That could work, even though you would have to pull out a list of 
enrolled students via the catalog.

But what happens when Johhny drops out of math because Mary isn't 
interrested in him anymore, and he wants to try his luck with Eve in the 
Science class?

    Math
        Mary
    Science
        Adam
        Eve
    History
        Science/Adam
        Science/Eve
        Math/Johnny #### No longer exists
        Math/Mary

Then you would need to write code that automatically moves Johhny to one 
of the places linking to Johnny ie. History. And then all the other 
classes linking to Math/Johnny would need to be told that they should 
now update their properties to link to History/Johnny.

I would hate to write that code. Also what is there is a list of student 
groups beside classes? They would also need to know where Johnny is 
moved to. And they should also have a copy of the code for updating the 
student properties.

Furthermore how would you display the students in a management 
interface? In Math Mary would be an item in a folder probably. But in 
History she would probably be a select box. That's bad too.

So the only logical approach is to put all objects that has many to many 
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


Another problem with the approach that you suggest is that for every 
distinct content type (product/metatype etc.) that you want to add, you 
have to ad logic and interface controlling the properties linking 
objects to each other.

This means that the amount of code you must write to support relations 
between object types in your site, grows squared with the number of 
different object types you want to relate.

And still it is a pain to do many to many relations. So the next logical 
step here would be to put the classes in their own folder too, and then 
have a product that only handles many to many relations::

    students/
        Johnny
        Mary
        Adam
        Eve
    classes/
        Math
        Science
        History
    Relations/
        classes/Math
            students/Johnny
            students/Mary
        classes/Science
            students/Adam
            students/Eve
        classes/History
            students/Adam
            students/Eve
            students/Johnny
            students/Mary
            
And then you would have another structure creating the view of the site, 
which could be like this::

    Home
        allClasses
            Math
                Johnny
                Mary
            Science
                Adam
                Eve
            History
                Adam
                Eve
                Johnny
                Mary
        allStudents
            Adam
                classes
                    Science
                    History
            Eve
                classes
                    Science
                    History
            Johnny
                classes
                    Math
                    History
            Mary
                classes
                    Math
                    History        


This way the code relating objects will only exist in the relations 
object, and when objects are moved they will only need to tell the 
relations object about it.

You could also change the view of the site without moving objects around.

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.

I hope this illuminates what I am trying to tell.

regards Max M