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