Steve Spicklemire wrote:
Hi Mike,
Hmmm.. how about just letting each instance of your ObjectManagerish ZClass contain a "DTML Method" called story_dtml or something. Then the index_html method of the Zclass could (among other things possibly..) call
<dtml-var story_dtml>
I have two objections: 1) aggregation is NOT inheritance. 2) when you try index such object in ZCatalog (I mean full text index) you get story_dtml indexed, not object itself. How will you handle such catalog entries?
which can then us all the tags your're talking about freely?
more soon I'm sure... ;-) -steve
Steve, my English is much better than your Russian ;-) Mike
Hi Mike,
"Mike" == Mike <mike@if-site.com> writes:
Mike> I have two objections: Mike> 1) aggregation is NOT inheritance. 2) when you try index Mike> such object in ZCatalog (I mean full text index) you get Mike> story_dtml indexed, not object itself. How will you handle Mike> such catalog entries? OK .. good point. It's a tradeoff between work up front (If you're going to do *that* much development... make a product in Python and you get fine-grained control over all the properties and behaviors you want/need) and elegance. On the shy side of elegance you might try beginning all your 'story' dtml documents with a call to a dtml method of the ZClass like this: <dtml-var beginStory> where beginStory is something like: <dtml-if "id()=='story_dtml'"> <dtml-call "RESPONSE.redirect(URL1)"> </dtml-if> I know.. it's a hack. You could clean it up a little... but it would work.. and you'd get all the benefits of a simple ObjectManager. -steve >> which can then us all the tags your're talking about freely? >> >> more soon I'm sure... ;-) -steve Mike> Steve, my English is much better than your Russian ;-) Mike> Mike
At 07:40 PM 2/8/00 +0700, Mike wrote:
Steve Spicklemire wrote:
Hi Mike,
Hmmm.. how about just letting each instance of your ObjectManagerish ZClass contain a "DTML Method" called story_dtml or something. Then the index_html method of the Zclass could (among other things possibly..) call
<dtml-var story_dtml>
I have two objections:
1) aggregation is NOT inheritance. 2) when you try index such object in ZCatalog (I mean full text index) you get story_dtml indexed, not object itself. How will you handle such catalog entries?
I've been working on something very similar for the past few weeks. I needed an object to hold onto a news article including attributes such as headline, publishing date, photo, etc. I created a ZClass called Article which derives from ZCatalogAware and ObjectManager (plus a couple others). I use a technique similar to the one described by Steve. I store my simple properties as properties, but I store the article in a DTMLMethod contained by my object under the name of "article_content". If there is a photo associated with the story, I store a CaptionedImage (another object I created) under the id of "photo". My article itself has no knowledge of how it might be displayed. The author of the article can include some HTML tags within the article itself for things like bold, italic, but more complex formatting is discouraged. I have developed several "view" objects (actually folders which contain DTMLMethods), which can display articles. So far this has worked quite well for me. As to your objections: 1. I'm not concerned about aggregation vs. inheritance. My Article inherits folder behavior which lets it maintain a collection of specific items relating to the article. I think of the collection as my objects instance variables. 2. I was concerned about this as well. However I have a solution which seems to work (there may be other solutions as well). All I did was create a ZCatalog and specified "article_content" as a TextIndex for the catalog. I did a Find for all objects with a meta-type of 'Article'. I was able to catalog all my articles and I can do full text searches as well even though the article content is in a DTMLMethod. There have been some other suggestions on this list to use the PrincipiaSearchSource mechanism. Hope you find this useful. Feel free to ask questions. James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
participants (3)
-
James W. Howe -
Mike -
Steve Spicklemire