R: [Zope] Discussion: Best practice site struture (LONG)
Hi Max, Your mail is very interesting for me, 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. 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... (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? Thank you. Michele
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
Hi Max, this is a VERY interesting thread to me now, very timely. I'm just starting to work on a zope product to list software, searchable by keyword and browsable by categories (see e.g. freshmeat.net); with user reviews and comments for each item (see e.g. amazon.com.) There are many items of software that might realistically belong in several distinct categories, and furthermore I want the page for each item to have links to browse all the categories that the item belongs to. 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. So you can see why your message is interesting to me... I was just about to post some questions to zope list re. ZODB vs. SQL for a site that needs this kind of flexible relationships *and* text searching. Further suggestions would be most welcome. Now some specific comments / questions... On Fri, Apr 05, 2002 at 09:56:28PM +0200, Max M wrote: 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
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?
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
Oh, I see. This is even better!
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? 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... All this is handled through methods of the Relations object? 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.
You could also change the view of the site without moving objects around.
Very nice.
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... -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
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
Looks like a job for the Entity-Relationship model to me. Take the example of teachers and classes. First we note that these are independent entities, ie they can exist independently of each other. So in an RDBMS, we'd end up with a table called called classes, and one called teachers, as well as one called class_teacher that expressed the relationship of a particular teacher teaching particular class. There would be two foreign key attributes in this class_teacher table, this table only needs to have two columns to properly relate a teacher to a class. These two attributes would be foreign key references to the other two tables, so that only class / teacher combinations where both the class and the teacher exist in their own respective tables would be allowed. The benefit you get here is that you can delete the class-teacher relationship and still have somewhere to store the class AND the teacher. You can store classes that do not yet have teachers, teachers that do not yet have classes, etc, and worry about relating the class to the teacher later. This kind of analysis of the data set that we want to work with, along with the practice of mapping the analysis to tables, attributes and constraints is well established in the RDBMS world. I have yet to get my head around mapping a complicated data set and the relationships between the data elements to an object database, like the ZODB :-) So, for now at least, the answer is PostgreSQL, and we use it *alot*. I should probably add that the Zope object tree you create to work with the RDBMS data can then reflect what users need to do with the data, rather than the data itself. In other words, Use Cases can be met with a collection of Zope objects that represent actions that users need to take. Adam At 03:05 AM 4/10/02, Max M wrote:
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
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Adam Manock wrote:
This kind of analysis of the data set that we want to work with, along with the practice of mapping the analysis to tables, attributes and constraints is well established in the RDBMS world. I have yet to get my head around mapping a complicated data set and the relationships between the data elements to an object database, like the ZODB :-) So, for now at least, the answer is PostgreSQL, and we use it *alot*.
Well in fact it is VERY easy to do in the ZODB. My mxmRelations product does exactly this. Only, a product like that should be in the core. More can be read here: http://www.zope.org/Members/maxm/productList/mxmRelations It has the disatvantage of not scaling very well, though it works nicely for most "normal" sized websites. But I will rewrite it at some time. It's currently at ver. 0.2, but I am using 0.3 in production right now that has a few added features. regards Max M
On Wed, 10 Apr 2002 14:49:39 +0200 "Max M" <maxm@mxm.dk> wrote:
Well in fact it is VERY easy to do in the ZODB. My mxmRelations product does exactly this. Only, a product like that should be in the core.
hi max and all the others who are interested in ZODB-Relation-Management, my idea for the mxmRelations (I call it RelationManager... think of the Zope-Cache-Managers) is that we need something like the following (yes, mxmRelations has some of the features already, but we need the management trough ZMI for easy use): - Each RelationManager should have two EntityContainers and one CrossTable. - Each EntityContainer can be filled up TTW with references to objects (think of the selection for a CacheManager... you can fill it up with all objects in entire Folders, all DTML-Documents with title == '*.doc' and so). So you can fill your Students easily into one EntityContainer and Classes into another. - In the CrossTable-View you can set or remove relations between elements of the EntityContainers with multiple selects and Relate-Or-Unrelate-Buttons. EntityContainer1 EntityContainer2 Student1 |----- Class1 Student2 |----- Class2 [Student1] --------| Class3 ... SetRelationButton DelRelationButton ... - Now you can create different RelationManagers for all kind of Relationships and talk to them if you want to know which relations between the objects exist. For example: You have RelationManagers for: Students<->Class Class<->Teachers Teachers<->Hobbies So if I want to know which Students visit Classes from Teachers with the Hobby of Bowling, I get all Teachers with Bowling-Hobby from Teachers<->Hobbies. Then I will get all the Classes from Class<->Teachers and then I will get the Students from Students<->Class. It's a little bit like a query in a relational database without SQL (should work with intersecting python lists...;-) - But the rocking point would be: each object which is related in a RelationManager should have an additional View where you can set and delete relations to and from this object. Something like the thing with the new Tab if you have created a CacheManager. I guess this must be a patch of the ObjectManager/SimpleItem/andSoOn-Code... thanks for listening... maik -- maik jablonski http://www.sachunterricht-online.de universitaet bielefeld http://www.zfl.uni-bielefeld.de zentrum fuer lehrerbildung tlph://+49.(0).521.106.4234
Max M wrote:
Well in fact it is VERY easy to do in the ZODB. My mxmRelations product does exactly this.
I'm using it right now (with a modification to add absolute_url to the attributes returned by smartlist) and I find it very useful, thank you, but still I think it is a hack: you do the relational magic by storing the path of the object. Move an object (copy & paste or rename) and the relation is gone (not a big deal, btw). Export a site using relations and import it in a different subtree and the relations are gone (this *is* a big deal: you can't safely use export/import). Delete an object, create another one with the same id and see the old relation pointing to it. The management interface should show dangling links instead of just hiding them. And if you want referential integrity you still have to code it by hand in each object (i.e. by implementing manage_beforeDelete). Even with these shortcomings it *is* an useful product, but I hope that relations in core zope are implemented with the set of features that a relational database gives you. Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
Luca Olivetti wrote:
Max M wrote:
Well in fact it is VERY easy to do in the ZODB. My mxmRelations product does exactly this.
I'm using it right now (with a modification to add absolute_url to the attributes returned by smartlist) and I find it very useful, thank you, but still I think it is a hack: you do the relational magic by storing the path of the object. Move an object (copy & paste or rename) and the relation is gone (not a big deal, btw).
Yes that is true. In my ver. 0.3 I have a few simple hooks (2 methods) that an object can call to keep relations even when they are moved. The product could be simpler if every object in Zope had a unique object Id. Then it could happen automatically.
Export a site using relations and import it in a different subtree and the relations are gone (this *is* a big deal: you can't safely use export/import). Delete an object, create another one with the same id and see the old relation pointing to it.
There is no easy solution to this. Currently the only "global object identifier" (goid) in zope is the path to the object. It's is sort of like the key in a rdbm's. When you move a bunch of objects to another location you change their "key". If you did this in a rdbm's you would get the same problem. Adding a true goid to Zope would not even solve this because the goids might allready be in use in the new zope instance you are copying to. What you probably should do is write a script that get's the links from one relations instance and then recreates them in the new one.
The management interface should show dangling links instead of just hiding them.
Not in the current implementation. The product currently deletes relations that no longer has valid objects. I did this so that you cannot remove an object with one meta_type and add one with another meta_type but the same id. This, I guess could seriously screw up the app. A possibility is to add the metatype to the relations and then keep the dead links instead ... that would also make a few other interresting oportunities possible and is a pretty simple change. But it does have the effect of filling up the database with dead relations And the more there are of them, the bigger the chance of a new object getting an unexpected relation. It is also possible to make a checkbox so that it's optional, but I think it is dangerous.
And if you want referential integrity you still have to code it by hand in each object (i.e. by implementing manage_beforeDelete).
This will probably never change. What should happen when an object is deleted is application and object specific and cannot be more generalized than to a hook.
Even with these shortcomings it *is* an useful product, but I hope that relations in core zope are implemented with the set of features that a relational database gives you.
Yes it could be better. But I think it's about as good as the current Zope allows. We need the ExplicitObjectReference goddarn it. regards Max M
Max M wrote:
The management interface should show dangling links instead of just hiding them.
Not in the current implementation. The product currently deletes relations that no longer has valid objects. I did this so that you cannot remove an object with one meta_type and add one with another meta_type but the same id. This, I guess could seriously screw up the app.
Maybe I was doing something stupid (with all that banging my head on the wall trying to learn zope+cmf+zpt+writing python products all at once ;-) but this is not what I saw: before I implemented manage_beforeDelete in my objects, I deleted one, I went to the management interface of the mxmRelation and saw that the relation wasn't there anymore -- good. Then I created a new object with the same id and when I went to display it the old relation was still in place -- bad. e.g. proposal1 -> company1 deleted proposal1 created new proposal1 (which should be unrelated to company1) and saw that the old relation was still in place. Since I didn't know of manage_beforeDelete at the time, in my object creation method I just put a call to delete dangling relations :-) [...]
And if you want referential integrity you still have to code it by hand in each object (i.e. by implementing manage_beforeDelete).
This will probably never change. What should happen when an object is deleted is application and object specific and cannot be more generalized than to a hook.
Well, there are not so many cases and with postgres (not that I'm an expert of it, it just happens that I read a tutorial about foreign keys and referential integrity ;-) you can define what happens when you delete a record another table depends on: 1) do nothing 2) cascade delete (i.e.delete the record and all records depending on it, useful for example if you're trying to delete an invoice and its lines) 3) don't allow deleting the record and that's it. But, as you say, that's not possible without modifications to zope core. Bye -- Luca Olivetti
Luca Olivetti wrote:
Max M wrote:
The management interface should show dangling links instead of just hiding them.
Not in the current implementation. The product currently deletes relations that no longer has valid objects. I did this so that you cannot remove an object with one meta_type and add one with another meta_type but the same id. This, I guess could seriously screw up the app.
Maybe I was doing something stupid (with all that banging my head on the wall trying to learn zope+cmf+zpt+writing python products all at once ;-) but this is not what I saw: before I implemented manage_beforeDelete in my objects, I deleted one, I went to the management interface of the mxmRelation and saw that the relation wasn't there anymore -- good. Then I created a new object with the same id and when I went to display it the old relation was still in place -- bad.
You are indeed right that it *can* happen. There is no way in Zope to subscribe to an object. So the relations class cannot know if an object is deleted before it tries to fetch it via the path. If the relations class cannot find an object it deletes it then. This means that if a new object is created between the old one being deleted and the next time the relations class tries to fetch it, that the link will still be there. That is not ideal of course.
Since I didn't know of manage_beforeDelete at the time, in my object creation method I just put a call to delete dangling relations :-)
The correct way to ensure that there are no dangling relations naturally is to create a method in any product being related to like (from the top of my head):: def manage_beforeDelete(self): self.relations.delete(self) Then things happens cleanly.
Well, there are not so many cases and with postgres (not that I'm an expert of it, it just happens that I read a tutorial about foreign keys and referential integrity ;-) you can define what happens when you delete a record another table depends on:
1) do nothing 2) cascade delete (i.e.delete the record and all records depending on it, useful for example if you're trying to delete an invoice and its lines) 3) don't allow deleting the record
and that's it. But, as you say, that's not possible without modifications to zope core.
I believe that will be more complex in Zope as objects are not as simple as tables and rows. regards Max M
Max M wrote:
The correct way to ensure that there are no dangling relations naturally is to create a method in any product being related to like (from the top of my head)::
def manage_beforeDelete(self): self.relations.delete(self)
Yup, that's what I did as soon I discovered manage_beforeDelete. But just to be sure I left the same call in my addObject method ;-) And in the manage_beforeDelete of the referenced object I perform a check to see if the object is used by other objects, and raise a BeforeDeleteException[*] in that case (any other exception would be logged by zope but would not stop the deletion). def manage_beforeDelete(self): if self.relations.get(self): raise BeforeDeleteException, ('Object in use') [*]in case it could be useful to someone else (to avoid some head banging ;-) from OFS.ObjectManager import BeforeDeleteException Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
Hi
From a form I have a lot of form variabes in the REQUEST object. The form processing method modify this form variables and set some new one in the REQUEST object. After it I'd like to redirect page with this modified variables. Can I append REQUEST variables to this command? <dtml-call "REQUEST.RESPONSE.redirect(pagename)"> Or I have to append to pagename the name and value of the variables one after the other?
halinux
Horvath Adam wrote:
Hi
From a form I have a lot of form variabes in the REQUEST object. The form processing method modify this form variables and set some new one in the REQUEST object. After it I'd like to redirect page with this modified variables. Can I append REQUEST variables to this command? <dtml-call "REQUEST.RESPONSE.redirect(pagename)"> Or I have to append to pagename the name and value of the variables one after the other?
i'm unsure, what you really want. redirect is something happening on the server while preparing to answer a browser request. with <dtml-call "REQUEST.RESPONSE.redirect(pagename)"> a redirect response is sent to the browser, which then will then request the new url from the server. http beeing stateless, all a redirect forgets all infos except when you use session tracking. keeping info after a redirect is pointless. if misunderstood, rephrase please. hans ------------------------------------------------------------- Who's got only a hammer sees the world as a nail hans augustin (software developer) hans@beehive.de beehive elektronische medien GmbH http://www.beehive.de phone: +49 30 847-82 0 fax: +49 30 847-82 299
Horvath Adam writes:
From a form I have a lot of form variabes in the REQUEST object. The form processing method modify this form variables and set some new one in the REQUEST object. After it I'd like to redirect page with this modified variables. Can I append REQUEST variables to this command? <dtml-call "REQUEST.RESPONSE.redirect(pagename)"> Or I have to append to pagename the name and value of the variables one after the other? The latter.
But maybe, my "emulateRedirect" external method can help you. See <http://www.dieter.handshake.de/pyprojects/zope> "urllib.urlencode" can also make it easier. You need to add a security declaration (see "README" in "PythonsScripts"!), before you can use it in Python scripts... Dieter
On Thursday, April 11, 2002, at 08:01 PM, Horvath Adam wrote:
From a form I have a lot of form variabes in the REQUEST object. The form processing method modify this form variables and set some new one in the REQUEST object. After it I'd like to redirect page with this modified variables. Can I append REQUEST variables to this command? <dtml-call "REQUEST.RESPONSE.redirect(pagename)">
You cannot do this with pure DTML. You need to use Python, calling urllib.urlencode( {'field': 'value','field2': 'value'} ) to build a string that can be appended to your URL.
Or I have to append to pagename the name and value of the variables one after the other?
Yes - the simplest way is using an external method and the urllib.urlencode function to do this. You can find all the arguments submitted to your script in REQUEST.form which can make things simpler. -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/
On Thu, Apr 11, 2002 at 10:33:45AM +0200, Max M wrote:
The correct way to ensure that there are no dangling relations naturally is to create a method in any product being related to like (from the top of my head)::
def manage_beforeDelete(self): self.relations.delete(self)
Then things happens cleanly.
But that means that every class you want to relate has to know about relations. I thought the relations were completely external to the related objects? Seems like you're breaking encapsulation. --PW
Paul Winkler wrote:
On Thu, Apr 11, 2002 at 10:33:45AM +0200, Max M wrote:
The correct way to ensure that there are no dangling relations naturally is to create a method in any product being related to like (from the top of my head)::
def manage_beforeDelete(self): self.relations.delete(self)
Then things happens cleanly.
But that means that every class you want to relate has to know about relations. I thought the relations were completely external to the related objects? Seems like you're breaking encapsulation.
No. self.relations.delete(self) happens through aquisition. regards Max M
On Thu, Apr 11, 2002 at 08:07:55PM +0200, Max M wrote:
No. self.relations.delete(self) happens through aquisition.
Whoops! I didn't even think of that. Acquisition... Sometimes I think it's the best thing since sliced bread. Sometimes it scares the sh*t out of me. :) -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
It seems that best practice for images is to keep the .gif, .jpg and .png extensions in filenames. Many web log analyzers such as wusage use Apache logs (or Z2.log) to generate statistics. Log analyzers try to report images and documents separately. Since the Apache or Z2.log does not contain "meta type", the analyzers must rely on the file extension. If the file has no extension, the log analyzer treat is as a directory. So if your homepage has 10 extension-less images, your web log report will say that: Most popular eleven directories were: / /img1 /img2
I'd agree, except that then product authors will have to force users to always use the graphic type that was originally chosen. i.e. if you use a product that has an image called "logo.jpg", and you want to use an image that is a gif or png, then you'd have to name a gif file "logo.jpg". I don't want to know what problems that might cause. I completely agree that it makes looking at WebTrends much more painful than it should be. -Paul Milos Prudek wrote:
It seems that best practice for images is to keep the .gif, .jpg and .png extensions in filenames.
Many web log analyzers such as wusage use Apache logs (or Z2.log) to generate statistics. Log analyzers try to report images and documents separately. Since the Apache or Z2.log does not contain "meta type", the analyzers must rely on the file extension.
If the file has no extension, the log analyzer treat is as a directory.
So if your homepage has 10 extension-less images, your web log report will say that:
Most popular eleven directories were: / /img1 /img2
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Max M wrote:
Adam Manock wrote:
This kind of analysis of the data set that we want to work with, along with the practice of mapping the analysis to tables, attributes and constraints is well established in the RDBMS world. I have yet to get my head around mapping a complicated data set and the relationships between the data elements to an object database, like the ZODB :-) So, for now at least, the answer is PostgreSQL, and we use it *alot*.
Well in fact it is VERY easy to do in the ZODB. My mxmRelations product does exactly this.
Only, a product like that should be in the core.
You can get use ZCatalog. Every objects needs a unique ID. For example "unique_id" Then the objects which refere to other objects have a list called "referenced_ids" Make an index for unique_id and referenced_ids. The two directions: 1. Finding the referenced objects: "for ref in referenced_ids: ..." 2. Finding the objects which refere to a given ID: Use ZCatalog.searchResults(referenced_ids=given_id) Maybe you could use catalogAware.getPath() instead of unique_id. thomas
participants (13)
-
Adam Manock -
Dieter Maurer -
hans -
Horvath Adam -
Luca Olivetti -
Maik Jablonski -
Max M -
Milos Prudek -
Paul Erickson -
Paul Winkler -
Stuart Bishop -
Thomas Guettler -
Zanotti Michele