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