Organisational vs. Functional hierarchies
I apologise if this is a newbie question, but I can't seem to find anything in the documentation about this. The way Zope seems to want to organise things is so that folders roughly equate to classes. That is, if I have B inside A, then B inherits its behaviour from A. All of B's siblings are the same sort of object. However, this means that I have to seperate all my various types of object by kind, regardless of whether they're related. Let's say I have a site that talks about flowers. I have two main kinds of object: images of flowers, which support methods for scaling etc, and descriptions of flowers, which support methods for rendering in various interesting ways. I have to arrange things like this: / Text HistoryOfTheDaisy MoreInformationAboutDaisies HowToGeneticallyEngineerRoses MyFavouriteRoseStories Images WildDaisy DomesticatedDaisy MutatedDaisyFromBeyondTimeAndSpace FakePictureOfABlackRose This works, but is a bit icky. I have my daisies mixed in with my roses. It would be far more convenient for organisational purposes if I arranged things like this: / Daisy Text HistoryOfTheDaisy MoreInformationAboutDaisies Images WildDaisy DomesticatedDaisy MutatedDaisyFromBeyondTimeAndSpace Rose Text HowToGeneticallyEngineerRoses MyFavouriteRoseStories Images MutatedDaisyFromBeyondTimeAndSpace FakePictureOfABlackRose But to make this work, I need to duplicate all the code in each 'Text' and 'Images' folder... Is it possible to tell Zope that methods for a particular kind of object should be found at a particular location, regardless of the containment hierarchy? That way I could have /lib/text and /lib/image that contain the reference code to make my text and images work; the Text and Images folders would then point at these. Or even better, I'd like to do without the Text and Images folders completely and just mix .pt and .jpg files in the Daisy and Rose folders. But I can't seem to find out whether I can do this. Is this in fact possible, or do I need to start tinkering with custom products? -- +- David Given --McQ-+ "Every planet is weird. I spent six weeks on a | dg@cowlark.com | moon where the principal form of recreation was | (dg@tao-group.com) | juggling geese. Baby geese. Goslings. They were +- www.cowlark.com --+ juggled." --- Firefly, _Our Mrs. Reynolds_
On Tue, Apr 19, 2005 at 04:31:15PM +0100, David Given wrote:
Is this in fact possible, or do I need to start tinkering with custom products?
That's what I would do. -- Paul Winkler http://www.slinkp.com
David Given wrote:
I apologise if this is a newbie question, but I can't seem to find anything in the documentation about this.
The way Zope seems to want to organise things is so that folders roughly equate to classes.
Nope.
That is, if I have B inside A, then B inherits its behaviour from A.
B acquire part of its behavior from A. But acquisition is not only by containment, it's also by context.
All of B's siblings are the same sort of object.
Why do you have this strange idea ?
However, this means that I have to seperate all my various types of object by kind, regardless of whether they're related.
Not at all. The most obvious think to do is to put your objects where they belongs - that is, use the ZODB hierarchie like you'd use a plain filesystem for a static site.
Let's say I have a site that talks about flowers. I have two main kinds of object: images of flowers, which support methods for scaling etc, and descriptions of flowers, which support methods for rendering in various interesting ways. I have to arrange things like this:
/ Text HistoryOfTheDaisy MoreInformationAboutDaisies HowToGeneticallyEngineerRoses MyFavouriteRoseStories Images WildDaisy DomesticatedDaisy MutatedDaisyFromBeyondTimeAndSpace FakePictureOfABlackRose
This works, but is a bit icky. I have my daisies mixed in with my roses.
It would be far more convenient for organisational purposes if I arranged things like this:
/ Daisy Text HistoryOfTheDaisy MoreInformationAboutDaisies Images WildDaisy DomesticatedDaisy MutatedDaisyFromBeyondTimeAndSpace Rose Text HowToGeneticallyEngineerRoses MyFavouriteRoseStories Images MutatedDaisyFromBeyondTimeAndSpace FakePictureOfABlackRose
But to make this work, I need to duplicate all the code in each 'Text' and 'Images' folder...
Nope. The most obvious thing to do is : put that code in your root folder. Now everyone will acquire it, and you'll be a happy webmaster. (unless of course there are name clashes somewhere !-)
Is it possible to tell Zope that methods for a particular kind of object should be found at a particular location, regardless of the containment hierarchy?
0/ Put all your code in the root folder and use acquisition by containment. Q&D, but proven to work. 1/ add (in the root folder, or anywhere on top of your Flowers) a folder for each 'type of object', put the 'methods' in, and use acquisition by context: text_methods dothis dothat image_methods: dosomething dosomethingelse Then calls like: Rose/Text/MyFavouriteRoseStories/text_methods/do_this Should work. But I would not do it (at least for your exemple). 2/ Write a product for your object types. Here it could be a Flower object, extending Folder so you can put texts and images in, and having all the code needed for your texts and images.
Is this in fact possible, or do I need to start tinkering with custom products?
Anyway, you *should* write your own Products - and for this kind of things, it's pretty easy. -- Bruno Desthuilliers Développeur bruno@modulix.org
On Tue, 2005-04-19 at 18:43 +0200, bruno modulix wrote: [...]
All of B's siblings are the same sort of object.
Why do you have this strange idea ?
From, uh, the documentation... because all of B's siblings will inherit the same methods from A. [...]
Then calls like: Rose/Text/MyFavouriteRoseStories/text_methods/do_this
Ah, so *that's* how acquisition by context works! (I couldn't find any documentation on this. All the documentation about acquisition by context just says 'this is really complicated and I'm not going to describe it here'.)
2/ Write a product for your object types. Here it could be a Flower object, extending Folder so you can put texts and images in, and having all the code needed for your texts and images.
Unfortunately, this requires having the code dealing with text and images to be in the same place, which breaks encapsulation. It actually looks like acquisition by context is most likely my best bet so far... Incidentally, is it possible to override the default behaviour of an object? Is there any way of allowing Rose/MyFavouriteRoseStories do something *other* than just executing the named page template, other than making MyFavouriteRoseStories a folder and overriding index_html? [...]
Anyway, you *should* write your own Products - and for this kind of things, it's pretty easy.
Meh. Can you point me at any good tutorial documentations? -- +- David Given --McQ-+ "The cup of Ireland's misfortunes has been | dg@cowlark.com | overflowing for centuries, and it is not full yet." | (dg@tao-group.com) | --- Sir Boyle Roche +- www.cowlark.com --+
On Tue, Apr 19, 2005 at 06:17:30PM +0100, David Given wrote:
On Tue, 2005-04-19 at 18:43 +0200, bruno modulix wrote: [...]
All of B's siblings are the same sort of object.
Why do you have this strange idea ?
From, uh, the documentation... because all of B's siblings will inherit the same methods from A.
Sure, but that doesn't constrain the types you can add to a folder. If you want to constrain availability of a method to instances of a particular class, then it should be written as a method of that class. Acquisition is meta_type-agnostic.
[...]
Then calls like: Rose/Text/MyFavouriteRoseStories/text_methods/do_this
Ah, so *that's* how acquisition by context works! (I couldn't find any documentation on this. All the documentation about acquisition by context just says 'this is really complicated and I'm not going to describe it here'.)
It's in the Advanced Scripting chapter of the online Zope Book, and there are some warnings about ways it can make your system harder to maintain.
Incidentally, is it possible to override the default behaviour of an object? Is there any way of allowing Rose/MyFavouriteRoseStories do something *other* than just executing the named page template, other than making MyFavouriteRoseStories a folder and overriding index_html?
[...]
Anyway, you *should* write your own Products - and for this kind of things, it's pretty easy.
Meh. Can you point me at any good tutorial documentations?
http://zopewiki.org/DiskBasedProduct - Paul Winkler http://www.slinkp.com
On Tue, 2005-04-19 at 13:40 -0400, Paul Winkler wrote: [...]
Sure, but that doesn't constrain the types you can add to a folder.
Unfortunately if you want the same method to do something different on a text file than on an image then you can't put them in the same folder... if you want to do it like that. [...]
Meh. Can you point me at any good tutorial documentations?
Ta. I'll check it out, although I suspect a ZClass may be more what I want... need to do some more reading up. -- +- David Given --McQ-+ "[One shot of the Death Star's superlaser has | dg@cowlark.com | enough power] to send Marty McFly to the Big Bang | (dg@tao-group.com) | and back 1.4x10^29 times." --- William Clifford +- www.cowlark.com --+
Ta. I'll check it out, although I suspect a ZClass may be more what I want... need to do some more reading up.
Don't use ZClasses. They have been deprecated for more than a year and they are poorly supported. -- Milos Prudek
On Wed, Apr 20, 2005 at 04:38:06PM +0200, Milos Prudek wrote:
Ta. I'll check it out, although I suspect a ZClass may be more what I want... need to do some more reading up.
Don't use ZClasses. They have been deprecated for more than a year and they are poorly supported.
Poorly supported, yes; officially deprecated, no. See the recent thread on this list, "Does anyone care whether we deprecate ZClasses?" In which Jim Fulton said, among other things: "...I'm not advocating that [removing ZClasses from zope 2.10]. I was asking if anyone cared. I strongly suspected that there would be people who did care. ... Many active Zope developers are (understandbly) dismissive of ZClasses, but I think we can't ignore the many people who depend on them." My interpretation: they aren't going away, but think twice before you get heavily invested in them now. -- Paul Winkler http://www.slinkp.com
On Wednesday 20 April 2005 16:53, Paul Winkler wrote: [...]
My interpretation: they aren't going away, but think twice before you get heavily invested in them now.
Well, having done some research, they do appear to be precisely what I'm looking for. They're simple, fast to develop, and everything can be done through ZMI, which is a huge plus. The actual amount of code I want to write is minimal; it looks like what I'll have is a subclass of File that processes its content and passes it as a parameter into a page template on itself. (What I actually want is a lightweight RestructuredText thing with more customisability.) It should be pretty trivial. Any gotchas I should know about? What other approaches are there to doing this kind of thing, other than writing a fully-fledged Product? -- +- David Given --McQ-+ | dg@cowlark.com | Quidquid latine dictum sit, altum viditur. | (dg@tao-group.com) | +- www.cowlark.com --+
On Wed, Apr 20, 2005 at 05:51:17PM +0100, David Given wrote:
Any gotchas I should know about?
I dunno, I never use 'em :-)
What other approaches are there to doing this kind of thing, other than writing a fully-fledged Product?
For creating new TTW types? I don't know of any, but that's not a use-case I need so I haven't gone looking. -- Paul Winkler http://www.slinkp.com
On 4/21/05, David Given <dg@cowlark.com> wrote:
The actual amount of code I want to write is minimal; it looks like what I'll have is a subclass of File that processes its content and passes it as a parameter into a page template on itself. (What I actually want is a lightweight RestructuredText thing with more customisability.) It should be pretty trivial.
Any gotchas I should know about?
careful what you subclass. don't do what i did (in 2000); subclass all the classes i think i want. now, i have to make sure all the dependent products are installed. some of them are not actually maintained anymore.
What other approaches are there to doing this kind of thing, other than writing a fully-fledged Product?
write a simple basic product. and subclass that for your zclass here's what i did: http://myzope.kedai.com.my/blogs/kedai/20
-- +- David Given --McQ-+ | dg@cowlark.com | Quidquid latine dictum sit, altum viditur. | (dg@tao-group.com) | +- www.cowlark.com --+ _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- http://myzope.kedai.com.my - my-zope org
On 4/19/05, David Given <dg@cowlark.com> wrote:
Unfortunately, this requires having the code dealing with text and images to be in the same place, which breaks encapsulation.
Zope is not a programming language. :-) Yes, Acquisition has similarieties to class inheritance, but it isn't, and trying to use is as if it was will just get strange. Acquisition can be handy for inheriting data (or rather, configuration), but not methods. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
On 4/19/05, David Given <dg@cowlark.com> wrote:
Unfortunately, this requires having the code dealing with text and images to be in the same place, which breaks encapsulation.
Zope is not a programming language. :-) Yes, Acquisition has similarieties to class inheritance, but it isn't, and trying to use is as if it was will just get strange.
Acquisition can be handy for inheriting data (or rather, configuration), but not methods.
Hmmm.... CMF skins (templates, Python Scripts, etc.) all work via acquisition; "placeful" scripting in general relies on it heavily. There is admittedly a lot of extra machinery in place to make sure that CMF objects select the "right" templates, based on their 'portal_type', but CMF / Plone / CPS wouldn't work at all without the ability to acquire software. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCZXR9GqWXf00rNCgRAsMRAJ4vZY7H908VNRDVCxzQAQEcaMPGdwCgjZ0S Ro/26CQSk0AbLQwCu+8IBrw= =jOMy -----END PGP SIGNATURE-----
Acquisition can be handy for inheriting data (or rather, configuration), but not methods.
Hmmm.... CMF skins (templates, Python Scripts, etc.) all work via acquisition; "placeful" scripting in general relies on it heavily. There is admittedly a lot of extra machinery in place to make sure that CMF objects select the "right" templates, based on their 'portal_type', but CMF / Plone / CPS wouldn't work at all without the ability to acquire software.
Ah, and you create nice contained classes with CMF skins? Or, do all object have all methods? CMF skins is not an object oriented programming language either. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Meh. Can you point me at any good tutorial documentations?
I just learned how to write products in about four hours by reading the following tutorials: Start with the minimal Product http://www.zope.org/Members/maxm/HowTo/minimal_01/ Then read about Boring product http://www.zope.org/Members/gtk/Boring and finish with JMBoring http://www.zope.org/Members/jmeile/JMBoring You then do not need to write your product from scratch. You can easily modify JMBoring. Thanks to Paul Winkler and Cliff Ford who pointed these excellent docs to me. -- Milos Prudek http://www.spoxdesign.com - your web usability testing
David Given wrote:
On Tue, 2005-04-19 at 18:43 +0200, bruno modulix wrote: [...]
All of B's siblings are the same sort of object.
Why do you have this strange idea ?
From, uh, the documentation... because all of B's siblings will inherit the same methods from A.
s/inherit/acquire/
[...]
Then calls like: Rose/Text/MyFavouriteRoseStories/text_methods/do_this
Ah, so *that's* how acquisition by context works! (I couldn't find any documentation on this. All the documentation about acquisition by context just says 'this is really complicated and I'm not going to describe it here'.)
It *is* really complicated, and I'd advise you not to go for this solution. What you want is clearly a Product.
2/ Write a product for your object types. Here it could be a Flower object, extending Folder so you can put texts and images in, and having all the code needed for your texts and images.
Unfortunately, this requires having the code dealing with text and images to be in the same place, which breaks encapsulation.
Why ? What you want is a custom "Flower" object, that can handle texts and images, right ? But if this bother you too much, you can add to your product specific texts and images classes (remember, a product is a componant, not a class - it can be composed of multiple classes, templates, images, external methods etc). (snip)
Meh. Can you point me at any good tutorial documentations?
google for zope + "minimal product". Also read the developper's book on zope.org. And read the code of a few products. That's how I did anyway. -- Bruno Desthuilliers Développeur bruno@modulix.org
On 4/19/05, David Given <dg@cowlark.com> wrote:
I apologise if this is a newbie question, but I can't seem to find anything in the documentation about this.
The way Zope seems to want to organise things is so that folders roughly equate to classes. That is, if I have B inside A, then B inherits its behaviour from A. All of B's siblings are the same sort of object.
You can do it like that, yes. You only HAVE to, if you develop everything with pythin scripts. Disk-based products overcome this completely.
But to make this work, I need to duplicate all the code in each 'Text' and 'Images' folder...
Well, no. You can just put all of it in the top folder. <ugh> :) Or, as mentioned above, make a python product.
Is this in fact possible, or do I need to start tinkering with custom products?
Well, you *should* in any case. ;) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
participants (7)
-
Bakhtiar A Hamid -
bruno modulix -
David Given -
Lennart Regebro -
Milos Prudek -
Paul Winkler -
Tres Seaver