AW: [Zope] one 'document' in many 'folders'
Correct me if I'm wrong, but the only way I see to do this *inside* the Zope application is to keep all your articles inside one folder (pool) and have key documents in your tree structure which reference an article in the pool. I don't know if problems appear when you establish an acyclic directed graph structure in the object hierarchy itself (I asked the question myself months ago without an answer). I see no point why it shouldn't work, but it is not maintained by the application. An interesting fact is that your object's properties vary when accessed by different paths due to the acquisition structure. An object inside Zope's database (again, correct me, if...) doesn't know about its father. It only knows about its sons, the aq_parent path is constructed on each access. Would also like to hear more about this... Stefan
-----Ursprüngliche Nachricht----- Von: Wade Leftwich [SMTP:wade@lightlink.com] Gesendet am: Montag, 22. März 1999 13:44 An: zope@zope.org Betreff: [Zope] one 'document' in many 'folders'
As a demonstration project to try and get a client to go with Zope, I'm converting a newsfeed database that I had originally built using Perl.
The object of the game is to pull fresh articles from a Reuters server every two hours and put them in a bin. A human editor goes through the bin, culls and sorts the articles, edits where appropriate.
One article may appear in more than one section of the site. For example, an article titled "Zope Is Cool" might appear in the Python, Web Development, and Open Source sections. Each section has its own contents page.
This is where I get confused. My Perl application simply used the filesystem as a database, and generated three separate static copies of "Zope Is Cool", placing one in each of three directories: /python, /web_development, and /open_source. I suspect there are much better ways to do it in Zope, but how do I organize things?
My naive idea is to make each article a Document, one of whose properties is a list (or dictionary) of categories in which it should be placed. Generating each section's contents page would then take some figuring out, and performance on doing the contents page would be a concern.
If there's a better way, I'd certainly appreciate hearing about it.
Signed,
Confused a/k/a
Wade Leftwich Okay Network Services, Ithaca NY tel 607-277-1334 fax 607-272-3612
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
What a great mailing list! I posted my question, shovelled the driveway (Ithaca NY, 8" of heavy wet snow last night), had breakfast and an extra cup of coffee, then came back to my desk to find 2 good answers. Thanks Stefan and Kevin. Well, on the one hand I'm pleased to hear that my question wasn't trivial. But I'm disappointed to hear that my problem is difficult. I'm competing against Cold Fusion here, and the problem resolves itself pretty easily with linked tables. (At least until I actually try to write the code.) So maybe I should just co-opt the competition and use ZSQL? But the odb is so nice, I really want to make it work that way. I don't really need for the URLs to look like a directory structure: instead of /open_source/zopeiscool, it would be okay for the article URL to be /zopeiscool?section=open_source. But that still leaves the problem of generating a contents page for each section. I suppose I could have a script that periodically-or-on-demand walks through the articles and generates a fresh static contents page for each section. Seems kind of non-zopish, but that might be the best way to get decent rendering performance on the contents page anyway. (The site is very active.)
an acyclic directed graph structure in the object hierarchy itself
Yow! The original question:
-----Ursprüngliche Nachricht----- Von: Wade Leftwich [SMTP:wade@lightlink.com] Gesendet am: Montag, 22. März 1999 13:44 An: zope@zope.org Betreff: [Zope] one 'document' in many 'folders'
As a demonstration project to try and get a client to go with Zope, I'm converting a newsfeed database that I had originally built using Perl.
The object of the game is to pull fresh articles from a Reuters server every two hours and put them in a bin. A human editor goes through the bin, culls and sorts the articles, edits where appropriate.
One article may appear in more than one section of the site. For example, an article titled "Zope Is Cool" might appear in the Python, Web Development, and Open Source sections. Each section has its own contents page.
This is where I get confused. My Perl application simply used the filesystem as a database, and generated three separate static copies of "Zope Is Cool", placing one in each of three directories: /python, /web_development, and /open_source. I suspect there are much better ways to do it in Zope, but how do I organize things?
My naive idea is to make each article a Document, one of whose properties is a list (or dictionary) of categories in which it should be placed. Generating each section's contents page would then take some figuring out, and performance on doing the contents page would be a concern.
If there's a better way, I'd certainly appreciate hearing about it.
Signed,
Confused a/k/a
Wade Leftwich Okay Network Services, Ithaca NY tel 607-277-1334 fax 607-272-3612
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
Sorry to post a commercial plug here, but it seems in stride with my post from this weekend to another question (Collector). Basically, Z Tables would be a pretty perfect fit (IMHO). I realize that you too realize that (sort of), because you suggested going the ZSQL route. Clearly, there are similarities. But, Z Tables has already been independently benchmarked as _kicking a**_ performance-wise, and is also more closely aligned with the gestalt that you indicated you liked about the object database. Just a thought (and a few bucks, of course :-).
Hadar Pedhazur wrote:
Sorry to post a commercial plug here, but it seems in stride with my post from this weekend to another question (Collector).
As long as it's you (i.e. important cause of Zope's open sourcing) posting commercial plugs on zope@zope.org, I doubt many people would mind. :) [ZTables] Although I'm still a complete ZTables newbie, I've seen ZTables come up repeatedly when there are similar design problems. This would indeed seem to indicate ZTables are a good fit. :) Regards, Martijn
Martijn Faassen wrote:
Although I'm still a complete ZTables newbie, I've seen ZTables come up repeatedly when there are similar design problems. This would indeed seem to indicate ZTables are a good fit. :)
I agree :-). Of course, this is precisely why we intend to release it (eventually) as Open Source(tm). We truly feel that the community will benefit, so we will release it. In the meantime, we're swamped, and prioritizing workload based on hard currency makes for simple decisions...
Stefan Franke wrote:
Correct me if I'm wrong, but the only way I see to do this *inside* the Zope application is to keep all your articles inside one folder (pool) and have key documents in your tree structure which reference an article in the pool.
You're wrong. ;) There are a numnber of ways to solve this. I suspect the simplest is to simply put the same object in multiple folders. (BTW, this is essentially the same thing as using Unix hard links.)
I don't know if problems appear when you establish an acyclic directed graph structure in the object hierarchy itself (I asked the question myself months ago without an answer).
Sorry you didn't get an answer. There is no problem with creating acyclic or cyclic graph constructors in the, uh, object hierarchy, which BTW, need not be a hierarchy. :)
I see no point why it shouldn't work, but it is not maintained by the application.
An interesting fact is that your object's properties vary when accessed by different paths due to the acquisition structure. An object inside Zope's database (again, correct me, if...) doesn't know about its father. It only knows about its sons, the aq_parent path is constructed on each access.
Yes, exactly. In fact, a better name for aq_parent might be aq_context.
Would also like to hear more about this...
Like what? :) Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.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 (5)
-
Hadar Pedhazur -
Jim Fulton -
Martijn Faassen -
Stefan Franke -
Wade Leftwich