I've been examining Zope with quite a bit of interest for a while now, and I have a question about the basic architecture: The object hierarchy seems to be 'exact', that is, strictly exclusive. No object can appear in more than one branch of the tree. However, In many cases, user oriented design requires several alternative navigation hierarchies, which would require objects to inherit from more than one branch. An example would be an event calendar, where events can be organized chronologicaly ( Years>Months>Days) but also according to an event category heirarchy (All events>entertainment>music>concerts). These heirarchies only intersect at the leaf node of an individual event. Most product catalogs can be profitably organized using multiple heirarchies as well. So how would you do this in Zope? you could of course represent the alternative heirarchies by branching off the bottom of the primary, or as folder properties, but that doesn't seem as elegant or maintainable. perhaps the answer is some sort of 'pseudo heirarchy' object that could be placed at or near the top of the object tree. What do you all think? Michael Bernstein.
Michael, I still feel like a dummy, so there are probably much better answers coming your way... but here's my take on things... I would expect that the organization of a ZOPESite conforms to what you are suggesting (strictness, etc), where acquisition plays a role in supplying parameters that control how the object services respond to the requests. Sure, some inheritance "across the tree" seems useful, and I think (if I understand what I've heard on this list), there are people thinking about how to do this. As I understand it, you're right... you need to implement things branch by branch, where maybe only a few things are different (parameterized templates would solve this maybe? smarter ones than I are working it). ANYWAY... Don't forget that one of the goals (IMO anyway) of ZOPE is to provide a clean separation between the presentation and the application layers of an application. You can have an application that is completely unaware of how its services are being exposed... This is a real cool concept and requires rethinking of how you build systems. (I haven't succeeded yet, but have been preaching this approach for several years). I am really looking forward to getting into the documents that Amos and crew have been working so hard on (I see that there is an ANNOUNCEMENT of another new Guide just ahead in my e-mail!) Anyway, if you read the DTML reference, etc, you'll see that two things need to be strived for: - Keep HTML out of the application classes - Keep application logic out of the DTML... let iterators, and other object accessors ask the exposed application object services for stuff. This is going to be (IMO) revolutionary in that it is going to facilitate demonstrating the difference between CORBA objects (durable services) and the transient objects provided by "object languages" such as Java, Python, Smalltalk, or even C++. Michael Bernstein wrote:
I've been examining Zope with quite a bit of interest for a while now, and I have a question about the basic architecture:
The object hierarchy seems to be 'exact', that is, strictly exclusive. No object can appear in more than one branch of the tree. However, In many cases, user oriented design requires several alternative navigation hierarchies, which would require objects to inherit from more than one branch.
An example would be an event calendar, where events can be organized chronologicaly ( Years>Months>Days) but also according to an event category heirarchy (All events>entertainment>music>concerts). These heirarchies only intersect at the leaf node of an individual event.
Most product catalogs can be profitably organized using multiple heirarchies as well.
So how would you do this in Zope? you could of course represent the alternative heirarchies by branching off the bottom of the primary, or as folder properties, but that doesn't seem as elegant or maintainable. perhaps the answer is some sort of 'pseudo heirarchy' object that could be placed at or near the top of the object tree.
What do you all think?
Michael Bernstein.
-- -- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) Still programming for the day-job... haven't yet gotten that Microsoft PR job ----------------------------------------------------------------------------- "PowerPoint -- the production platform of choice of the 'Big 6'." -me "The harder truth is that just because a company is spending a large amount on IT doesn't necessarily mean it's spending that money well." -- InformationWeek, Dec 8 1997, Pg 66 in "Old Countries, New Technologies" "But it sure is easier just to sit back and bitch than to actually try to make yourself heard." -- Jim Edwards-Hewitt meanwhile... "I'm not one of those who think Bill Gates is the devil. I simply suspect that if Microsoft ever met up with the devil, it wouldn't need an interpreter." -- Nicholas Petreley, InfoWorld editor. Remember: The enthusiasm for having chosen "NT" is at its maximum at t=-1. -----------------------------------------------------------------------------
Michael Bernstein wrote:
An example would be an event calendar, where events can be organized chronologicaly ( Years>Months>Days) but also according to an event category heirarchy (All events>entertainment>music>concerts). These heirarchies only intersect at the leaf node of an individual event.
Most product catalogs can be profitably organized using multiple heirarchies as well.
So how would you do this in Zope? you could of course represent the alternative heirarchies by branching off the bottom of the primary, or as folder properties, but that doesn't seem as elegant or maintainable. perhaps the answer is some sort of 'pseudo heirarchy' object that could be placed at or near the top of the object tree.
What do you all think?
It would be nice if Zope object hierarchy wouldn't be a hierarchy :-) Instead of a object tree we would have a object lattice. This is viable since we always have the info about which path to follow in the lattice, it is the object URL. It would be great for multilingual web sites. We would have paths to the same object like: http://www.mysite.com/section/object #default language http://www.mysite.com/french/section/object #french view of the site http://www.mysite.com/german/section/object #german view I vote for it! :-) []s -- Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html
Paulo Eduardo Neves wrote:
Michael Bernstein wrote:
An example would be an event calendar, where events can be organized chronologicaly ( Years>Months>Days) but also according to an event category heirarchy (All events>entertainment>music>concerts). These heirarchies only intersect at the leaf node of an individual event.
Most product catalogs can be profitably organized using multiple heirarchies as well.
So how would you do this in Zope? you could of course represent the alternative heirarchies by branching off the bottom of the primary, or as folder properties, but that doesn't seem as elegant or maintainable. perhaps the answer is some sort of 'pseudo heirarchy' object that could be placed at or near the top of the object tree.
What do you all think?
It would be nice if Zope object hierarchy wouldn't be a hierarchy :-) Instead of a object tree we would have a object lattice. This is viable since we always have the info about which path to follow in the lattice, it is the object URL.
It would be great for multilingual web sites. We would have paths to the same object like: http://www.mysite.com/section/object #default language http://www.mysite.com/french/section/object #french view of the site http://www.mysite.com/german/section/object #german view
Wouldn't a simple change (don't even know if its needed) involving the way the ORB works be enough? A simple way to do this: you write a folderish object that is able to "intercept" ORB requests to its children and can process the URL invocation itself? Perhaps by rewriting and redispatching the request? Wouldn't that be enough? e.g.: http://www.mysite.com/redirector/chinese/welcome http://www.mysite.com/redirector/english/welcome http://www.mysite.com/redirector/esperanto/welcome -Gabe
Gabe Wachob wrote:
Paulo Eduardo Neves wrote:
Wouldn't a simple change (don't even know if its needed) involving the way the ORB works be enough?
A simple way to do this: you write a folderish object that is able to "intercept" ORB requests to its children and can process the URL invocation itself? Perhaps by rewriting and redispatching the request? Wouldn't that be enough?
e.g.:
http://www.mysite.com/redirector/chinese/welcome http://www.mysite.com/redirector/english/welcome http://www.mysite.com/redirector/esperanto/welcome
Sorry, I tried to understand what you were saying but I didn't get it. Could you explain in a bit more detail? I am trying to come up with a general solution to multi-dimensional information spaces, rather than a solution to a specific instance. BTW, as I state in another post, I do not consider myself a programmer, but an Information Architect. I am hoping that these ideas are interesting enough for someone to implement. Michael Bernstein.
Paulo Eduardo Neves wrote:
Michael Bernstein wrote:
An example would be an event calendar, where events can be organized chronologicaly ( Years>Months>Days) but also according to an event category heirarchy (All events>entertainment>music>concerts). These heirarchies only intersect at the leaf node of an individual event.
Most product catalogs can be profitably organized using multiple heirarchies as well.
So how would you do this in Zope? you could of course represent the alternative heirarchies by branching off the bottom of the primary, or as folder properties, but that doesn't seem as elegant or maintainable. perhaps the answer is some sort of 'pseudo heirarchy' object that could be placed at or near the top of the object tree.
What do you all think?
It would be nice if Zope object hierarchy wouldn't be a hierarchy :-) Instead of a object tree we would have a object lattice. This is viable since we always have the info about which path to follow in the lattice, it is the object URL.
Yes, this was what I meant. Each individual 'pseudo hierarchy' object is still a strict hierarchy, but because they intersect, the actual content structure of the site as a whole is a multidimensional lattice. This has several uses, such as the ability to show alternative content depending on a second top level hierarchy (as with your language example), or if you are using the additional hierarchy to represent a different organization of the same content, your server logs will very explicitly show what navigation methods are preferred by your users. One other idea I had was to have path dependent navigation rendering, instead of just context dependent navigation. Any comments? Michael Bernstein.
At 2:05 PM -0800 1/21/99, Michael Bernstein wrote:
Yes, this was what I meant. Each individual 'pseudo hierarchy' object is still a strict hierarchy, but because they intersect, the actual content structure of the site as a whole is a multidimensional lattice.
This has several uses, such as the ability to show alternative content depending on a second top level hierarchy (as with your language example), or if you are using the additional hierarchy to represent a different organization of the same content, your server logs will very explicitly show what navigation methods are preferred by your users. One other idea I had was to have path dependent navigation rendering, instead of just context dependent navigation.
Any comments?
Michael Bernstein. Comments? Thank you Thank you Thank you. I have been struggeling with a metaphor for exactly that. You have put it into words for me, "Lattice" is an excellent name. I agree with you completely that this would be a great addition to Zope!
DAve. "On the Plains of Hesitation bleach the bones of countless millions who, at the Dawn of Victory, sat down to wait, and waiting -- died"
Dave G wrote:
At 2:05 PM -0800 1/21/99, Michael Bernstein wrote:
Yes, this was what I meant. Each individual 'pseudo hierarchy' object is still a strict hierarchy, but because they intersect, the actual content structure of the site as a whole is a multidimensional lattice.
<snip>
Any comments?
Michael Bernstein. Comments? Thank you Thank you Thank you. I have been struggeling with a metaphor for exactly that. You have put it into words for me, "Lattice" is an excellent name. I agree with you completely that this would be a great addition to Zope!
Let me just clarify, I am not proposing a major change to the zope interface. the current 'tree' structure of a site is just too useful. I am suggesting however, that in order to accomplish multiple inheritance, alternative path navigation, and other 'Good Things', that we have the ability to add 'branch' type folderish objects that can contain other 'branches' or 'leaves'. Other objects lower in the main heirarchy can be assigned to a 'leaf' in each additional 'branch' above them. This in essence, would let us: 1) factor content and functionality that we currently cannot (or at least, not as easily). ('is a' inheritance) 2) provide alternative navigation to the same content ('in a' inheritance) 2a) path dependent navigation and content rendering (by giving precedence to the path taken, where properties or methods conflict) 2b) explicit and simple path analysis from server logs I think I'm repeating myself. Add to the list if you can think of other applications. As with any powerful tool, there is potential for abuse, and someone could easily construct a site that was incredibly convoluted and unmaintainable, if they weren't careful. to help avoid that, you would probably want to disallow assigning a leaf in one tree to a leaf in another tree for example. Or maybe not. What do you all think? Michael
At 4:51 PM -0800 1/21/99, Michael Bernstein wrote:
Dave G wrote:
Comments? Thank you Thank you Thank you. I have been struggeling with a metaphor for exactly that. You have put it into words for me, "Lattice" is an excellent name. I agree with you completely that this would be a great addition to Zope!
Let me just clarify, I am not proposing a major change to the zope interface. the current 'tree' structure of a site is just too useful. I am suggesting however, that in order to accomplish multiple inheritance, alternative path navigation, and other 'Good Things', that we have the ability to add 'branch' type folderish objects that can contain other 'branches' or 'leaves'. Other objects lower in the main heirarchy can be assigned to a 'leaf' in each additional 'branch' above them.
This in essence, would let us: 1) factor content and functionality that we currently cannot (or at least, not as easily). ('is a' inheritance) 2) provide alternative navigation to the same content ('in a' inheritance) 2a) path dependent navigation and content rendering (by giving precedence to the path taken, where properties or methods conflict) 2b) explicit and simple path analysis from server logs
I think I'm repeating myself. Add to the list if you can think of other applications.
As with any powerful tool, there is potential for abuse, and someone could easily construct a site that was incredibly convoluted and unmaintainable, if they weren't careful.
to help avoid that, you would probably want to disallow assigning a leaf in one tree to a leaf in another tree for example. Or maybe not.
What do you all think?
Michael
Correct, I don't see a need to change Zope's structure, but some tools to use it's features in a non linear manner would be nice. 3) dynamic creation or shaping of properties based on navigation paths. 4) alternative rendering of content based on instance 4a) 'if in a' else 'in b' Does that make sense? DAve. "On the Plains of Hesitation bleach the bones of countless millions who, at the Dawn of Victory, sat down to wait, and waiting -- died"
Dave G wrote:
At 4:51 PM -0800 1/21/99, Michael Bernstein wrote:
This in essence, would let us: 1) factor content and functionality that we currently cannot (or at least, not as easily). ('is a' inheritance) 2) provide alternative navigation to the same content ('in a' inheritance) 2a) path dependent navigation and content rendering (by giving precedence to the path taken, where properties or methods conflict) 2b) explicit and simple path analysis from server logs
I think I'm repeating myself. Add to the list if you can think of other applications.
3) dynamic creation or shaping of properties based on navigation paths. 4) alternative rendering of content based on instance 4a) 'if in a' else 'in b'
Does that make sense?
Yes, although I was primarily thinking of placing methods and documents (headers, navbars) into the 'branch' objects to change how content and context is displayed. Attaching properties to them to control which content is displayed should be possible too, though I wouldn't go overboard with it. I would rather put switching properties into the branches, and leave the switching logic in the actual content folders default document (although that could still be acquired from higher in the 'normal' or 'primary' heirarchy). For this to work, you would need a structure like this (please forgive the pseudocode): ----------------------------- Root /Branch_Language /Leaf_French language_property = F /Leaf_Russian language_property = R /Content Assign to Branch_Language/Leaf_French Assign to Branch_Language/Leaf_Russian /index_html /default_content /french_content /russian_content ----------------------------- Then, since the property 'language_property' has conflicting values, zope would use the one that takes precedence as a result of the users actual URL path. The 'index_html' document would then contain a simple conditional statement to insert the correct <!--#var -->. Subsequent sub-folders from /Root/Content would just need the appropriate content documents. This would require, in contrast to an earlier idea of mine, the ability to make assignments to more than one location within the same 'branch'. Note: This example is an expansion of an idea presented earlier by Paulo Eduardo Neves. I will submit an example of alternate navigation paths to the same content in a subsequent posting. Michael Bernstein. P.S. I consider myself an Information Architect, not a programmer. I am presenting these ideas in the hope that someone on this list will find them interesting enough to implement.
Ok, Here are my thoughts on an alternative navigation setup to the same content. I am changing the nomenclature to better fit the generalized approach I am taking here. Each alternative hierarchy begins with a 'schema' folderish object, which can contain 'node' folderish objects. 'node' objects can contain other 'node' objects, as well as documents, images, and properties. Only the bottom layer of 'nodes' (leaf nodes) is available for assignment. Again please forgive the simplification and pseudocode. I am going to use as an example a fictional military memorabilia site. ----------------------------- Root /Items /index_html #document /Uniforms #folder /Weapons #folder /Firearms #folder /gun1 #folder Assign to Schema_HistoricalPeriod/Node_WWII Assign to Schema_Nationality/Node_American desc_html #document /Knives #folder /knife1 #folder Assign to Schema_HistoricalPeriod/Node_WWI Assign to Schema_Nationality/Node_American desc_html #document /knife2 #folder Assign to Schema_HistoricalPeriod/Node_WWII Assign to Schema_Nationality/Node_German desc_html #document /Schema_HistoricalPeriod /Node_WWI /Node_WWII /Schema_Nationality /Node_German /Node_American ----------------------------- This particular type of site can have people navigating to items according to many more different classification schemas then I've listed here. Since acquisition runs both ways, it should be trivial to navigate to Root/Schema_HistoricalPeriod/Node_WWII and see links to both gun1_html and knife2_html. Specialized content can be acquired from the various nodes, such as flag icons denoting nationality from the nodes under Schema_Nationality, off site links to historical sites from under Schema_HistoricalPeriod, etc. Most importantly, if I navigate to Root/Schema_HistoricalPeriod/Node_WWII/knife2 , I should be able to have a link in Root/items/index_html to Parent.Schema_Nationality and arrive at Root/Schema_Nationality/Node_German and see all the other german items in the site (again please forgive the pseudocode). Any comments? BTW, if anyone thinks that this is NOT a valid idea, please let me know. Michael Bernstein
Date: Thu, 21 Jan 1999 19:21:12 -0300 From: Paulo Eduardo Neves <neves@inf.puc-rio.br> Organization: PUC-Rio To: Michael Bernstein <mbernstein@profitscape.net> Cc: zope@zope.org Subject: Re: [Zope] - OO paradigm
Michael Bernstein wrote:
An example would be an event calendar, where events can be organized chronologicaly ( Years>Months>Days) but also according to an event category heirarchy (All events>entertainment>music>concerts). These heirarchies only intersect at the leaf node of an individual event.
Most product catalogs can be profitably organized using multiple heirarchies as well.
So how would you do this in Zope? you could of course represent the alternative heirarchies by branching off the bottom of the primary, or as folder properties, but that doesn't seem as elegant or maintainable. perhaps the answer is some sort of 'pseudo heirarchy' object that could be placed at or near the top of the object tree.
What do you all think?
It would be nice if Zope object hierarchy wouldn't be a hierarchy :-) Instead of a object tree we would have a object lattice. This is viable since we always have the info about which path to follow in the lattice, it is the object URL.
It would be great for multilingual web sites. We would have paths to the same object like: http://www.mysite.com/section/object #default language http://www.mysite.com/french/section/object #french view of the site http://www.mysite.com/german/section/object #german view
I vote for it! :-)
[]s -- Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html
This is an interesting idea. I am currently implementing our Web site in Zope (we use 5 different languages now, will be adding a sixth and maybe a seventh). My solution has been to separate the format and the content, leaving standard things like headers and footers in the "keystone" directories (ie. www.mysite.org/Euskera/) to be used in general. For the objects that are reapeated (index_html), I have copied the format, and changed the content (which is in a separate object). I have tried to make the links relative, since we want to have all of our content repeated. Of course, I am not sure if this is really the best way to do this, by the way. Any suggestions would be welcome. What exactly is the advantage of a lattice setup in this situation (except saving on copying the templates)? How exactly would it work? I don't think I really understand this idea. Thanks, JP JP Glutting jpglutting@mx3.redestb.es
Michael Bernstein wrote:
I've been examining Zope with quite a bit of interest for a while now, and I have a question about the basic architecture:
The object hierarchy seems to be 'exact', that is, strictly exclusive. No object can appear in more than one branch of the tree.
No, this is not the case. There is nothing in the architecture of Zope to prevent placing an object in more than one place in the object space. None of the existing standard objects provide an interface for doing this, but you could do it in Python. In fact, because of the way the database works, you can have circular references without running into memory management problems,
However, In many cases, user oriented design requires several alternative navigation hierarchies, which would require objects to inherit from more than one branch.
Please don't use the word "inherit" in this context. An object can be accessed in more than one context and therefore acquire context dependent information.
An example would be an event calendar, where events can be organized chronologicaly ( Years>Months>Days) but also according to an event category heirarchy (All events>entertainment>music>concerts). These heirarchies only intersect at the leaf node of an individual event.
This is exactly what Z Tables (the thing formerly known as Tabula) lets you do.
Most product catalogs can be profitably organized using multiple heirarchies as well.
Yup.
So how would you do this in Zope?
You can create any object structures you want. How would you do it in Python? In Z Tables, we have a data structure that holds basic data and then other data structures that organize that data in various ways. You could also physically store objects in multiple containes (e.g. folders).
you could of course represent the alternative heirarchies by branching off the bottom of the primary, or as folder properties, but that doesn't seem as elegant or maintainable. perhaps the answer is some sort of 'pseudo heirarchy' object that could be placed at or near the top of the object tree.
Yes, something like that would work too. There are many ways that this sort of thing could be accomplished. The "right" way may depend on ths application. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (7)
-
Dave G -
Gabe Wachob -
Jim Fulton -
jpglutting＠mx3.redestb.es -
LD Landis -
Michael Bernstein -
Paulo Eduardo Neves