Generic Content Object for use with Page Templates
I've been using Zope for a while now, and I'm a little miffed that I don't really know the answer to this. Having finally succumbed to the preachings of the 'Withers Church of the Page Template', I thought I'd give them a shot for a site I'm building. So, I've got myself setup up with and index_html page template that I want to use to present the content of my site. Obviously, I could use more zpts to hold my content, but I don't really like that idea coz I just want to store the 'meat in the sandwich' (of standard_html_header/footer as it was) - zpts seem overkill and potentially a little confusing for naive users. http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZPT.stx#2-90 mentions that this is not appropriate and mentions some alternative content objects. However, it says CMF solves this issue - and I'm not using CMF, so... I could use DTML Documents, but I don't want the user to be able to write DTML really, and recent posts, coupled with ChrisMcD's 2.6 Edition Zope Book lead me to believe that way lies the dark side. DTML Methods clearly aren't right. I want properties anyway. STX - haven't used it but it looks like it could be handy. Still, I want my users to be able to bash out some html when editing. Files - may be appropriate as they can just store text and can be edited through the ZMI if less than 64KB I believe. Still, if I want to have the index_html zpt present the contents, I'll have to have urls explicitly of the form file/index_html, otherwise I presume I'll just get a file download prompt from my browser. So, I think I'm left with Folders. If I store my text as a property of a Folder (and adjust my zpt to reflect this), I can have an auto-presenting content object that doesn't require users to remember to slap the bread around their meat (if you know what I mean ;-) ). Are Folders the content object of choice in this case then, or am I missing something. BTW, I'd rather not have to use objects that aren't bundled zope as I have to fight for every additional product that is installed. Thoughts anyone? tim
Tim Hicks wrote:
Files - may be appropriate as they can just store text and can be edited through the ZMI if less than 64KB I believe. Still, if I want to have the index_html zpt present the contents, I'll have to have urls explicitly of the form file/index_html, otherwise I presume I'll just get a file download prompt from my browser.
If you really want to work it this way, you can use a Folder containing a text/plain File. For example, if you standardize on the name 'content.html' for the File object, your index_html ZPT can use: <div tal:replace="structure here/content.html">Content</div> This way, you still have a convient ZMI interface (especially with ExternalEditor!) for your content. Cheers, Evan @ 4-am
Tim Hicks wrote:
Files - may be appropriate as they can just store text and can be edited through the ZMI if less than 64KB I believe. Still, if I want to have the index_html zpt present the contents, I'll have to have urls explicitly of the form file/index_html, otherwise I presume I'll just get a file download prompt from my browser.
If you really want to work it this way, you can use a Folder containing a text/plain File. For example, if you standardize on the name 'content.html' for the File object, your index_html ZPT can use:
<div tal:replace="structure here/content.html">Content</div>
This way, you still have a convient ZMI interface (especially with ExternalEditor!) for your content.
Nice idea, thanks. But I get the feeling that it's not something you'd do yourself ("If you really want to work it this way...") - why is that and do you have alternative site structures? cheers tim
Tim Hicks wrote:
But I get the feeling that it's not something you'd do yourself ("If you really want to work it this way...") - why is that and do you have alternative site structures?
In the past, I've used plain File objects when I needed a quick & dirty content object. This works for me since I don't try to traverse them directly, only refer to them. By this I mean that I might have a Folder 'news' that contains Files like '2002082101', but I never try to send the user to "http://.../news/2002082101". I'll have a news page at "http://.../news", and if a user is managing a piece of content, they'll be at "http://.../news/edit?nid=2002082101". Obviously, this may not work for you if you have a different model for user interaction with content. If you can, I advise using the CMF. Cheers, Evan @ 4-am
On Wed, Aug 21, 2002 at 04:44:29PM -0500, Evan Simpson wrote:
Obviously, this may not work for you if you have a different model for user interaction with content. If you can, I advise using the CMF.
This brings up an issue I'm dealing with currently... I've got largish amounts of content objects which need to be managed by a small (under 10) group of people internally, and viewed (not managed) on the internet. We're moving to using CMF-based solutions for management, but for presentation to the outside world, the "portal" metaphor isn't really that relevant - our site is not personalizable (is that a word?), nor can the general public log in. And we have a design for the site which doesn't look anything lke an existing CMF skin. I see two options: 1) Create a skin for the public which hides all the management stuff (and, in fact, looks & feels *completely* different from the management skin). 2) Create a separate section of our site which is purely for presentation, and pulls content out of CMF. (love that CookedBody() method!) Has anyone gone down either or both of these paths? Any comments on pros & cons of either approach? I have a feeling that option 2 might be easier to manage in terms of security. - Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
Paul Winkler wrote:
On Wed, Aug 21, 2002 at 04:44:29PM -0500, Evan Simpson wrote:
Obviously, this may not work for you if you have a different model for user interaction with content. If you can, I advise using the CMF.
This brings up an issue I'm dealing with currently...
I've got largish amounts of content objects which need to be managed by a small (under 10) group of people internally, and viewed (not managed) on the internet. We're moving to using CMF-based solutions for management, but for presentation to the outside world, the "portal" metaphor isn't really that relevant - our site is not personalizable (is that a word?), nor can the general public log in. And we have a design for the site which doesn't look anything lke an existing CMF skin.
I see two options:
1) Create a skin for the public which hides all the management stuff (and, in fact, looks & feels *completely* different from the management skin).
2) Create a separate section of our site which is purely for presentation, and pulls content out of CMF. (love that CookedBody() method!)
Has anyone gone down either or both of these paths? Any comments on pros & cons of either approach?
I have a feeling that option 2 might be easier to manage in terms of security.
Paul, its sound like you never used the CMF in a project, and are therefore in a situation like me some months before. Even if not, I'll just write down my experience when using CMF, maybe it's informative for someone else . I always heard how cool CMF is and what nice solutions you get when using it - and everytime I looked at it/installed it, it looked like a framework for community driven slashcode sites. Only when I had the problem of giving users several "intelligent" templates to work with, freely interchangeable even after creating the content, I got the tip to look at CMF. I had to use a fs-based product from the beginning and first looked at the CMF-equivalent (roughly) of the nice mxmEasyProduct - don't remembe the name ATM, to see what stuff a CMF product has to implement. I didn't like the CMF mgmnt-interface, so I wrote a "hybrid" product of some sort, because it uses the ZMI for its interface. I think of this memberstuff and skin stuff as services, and the stock CMF stuff as an "maximal" example application which just tries to show off anything the CMF has to offer. Arguably not in an optimal form - the stock ZMI interface is really more convenient than the CMF interface IMO. But that this represents the "portal" metaphor is not surprising, because the concept of a portal aims to use any technology which is available to enrich its content. But using the CMF is really a joy and is probably not limited to building community sites, it's really zope-as-a-publishing-system taken to the next level of existence. Just replace _all_ of the standard skins with your own, and you are as productive as with a zope python product, just much more flexible. cheers, oliver
On Thu, Aug 22, 2002 at 01:00:28AM +0200, Oliver Bleutgen wrote:
Paul, its sound like you never used the CMF in a project, and are therefore in a situation like me some months before.
Well, not exactly. I've previously built a site on CMF - starting way back when it was PTK! But we really didn't need more than one look&feel, so this is a whole other ball of wax.
I didn't like the CMF mgmnt-interface, so I wrote a "hybrid" product of some sort, because it uses the ZMI for its interface.
For us, the CMF interface is quite good for the people that need to manage content. But nearly all of it is irrelevant for our general audience.
Just replace _all_ of the standard skins with your own, and you are as productive as with a zope python product, just much more flexible.
hmmm. OK, I'll look more closely at how to do what I want solely within CMF, and see if it looks like a win. Things like skins that are only available to certain roles, and skin layers that only apply in certain folders, and very precise control of what the content managers can and can't do. Can't have them deleting a folder that contains logic objects which they don't know are there... -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
Paul Winkler wrote:
Just replace _all_ of the standard skins with your own, and you are as productive as with a zope python product, just much more flexible.
hmmm. OK, I'll look more closely at how to do what I want solely within CMF, and see if it looks like a win.
Things like skins that are only available to certain roles, and skin layers that only apply in certain folders, and very precise control of what the content managers can and can't do. Can't have them deleting a folder that contains logic objects which they don't know are there...
Well, you still have the same security framework like you have in stock zope, so use that to control who can do what. Then you just have to make sure when writing your skins that people don't see knobs they are not allowed to touch. cheers, oliver
Tim Hicks wrote:
But I get the feeling that it's not something you'd do yourself ("If you really want to work it this way...") - why is that and do you have alternative site structures?
In the past, I've used plain File objects when I needed a quick & dirty content object. This works for me since I don't try to traverse them directly, only refer to them. By this I mean that I might have a Folder 'news' that contains Files like '2002082101', but I never try to send the user to "http://.../news/2002082101". I'll have a news page at "http://.../news", and if a user is managing a piece of content, they'll be at "http://.../news/edit?nid=2002082101".
Should I presume you term File objects as 'quick and dirty content objects' coz when you don't want to be 'quick and dirty', you roll your own?
Obviously, this may not work for you if you have a different model for user interaction with content. If you can, I advise using the CMF.
Thanks for the input. For me, the slate is actually fairly clean, so I could potentially use such a system as you describe. As for the CMF, I'm not a convert yet, so I think I'll steer clear for now. cheers, tim
Hi Tim, The ancestor of the Page Templates is HiperDOM, the last versions of HiperDOM released by Lalo Martins had a class named DataObject whose purpose is exactly the one you describe. So the idea was HiperDOM templates for presentation and DataObject instances for content (just replace HiperDOM by ZPT or DTML). You can still get HiperDOM from: http://www.zope.org/Members/lalo/HiperDom/ Unfortunately Zope don't has any standard object for this, and development of DataObject stopped with the development of HiperDOM, as far as I know. But, the DataObject class inspired what now is the LocalContent class of the Localizer product. The LocalContent class is specially focused in multilingual content. But, of course, you can use it to store only one language version, after all multilingual content can be seen as a generalization of monolingual content. If you're interested you can download Localizer from: http://sourceforge.net/projects/lleu If you want to try it use Localizer 0.8.1, the 0.9.0 version depends on Zope 2.6 (because it needs the Unicode support that Zope 2.6 includes). Best regards, Tim Hicks wrote:
I've been using Zope for a while now, and I'm a little miffed that I don't really know the answer to this. Having finally succumbed to the preachings of the 'Withers Church of the Page Template', I thought I'd give them a shot for a site I'm building.
So, I've got myself setup up with and index_html page template that I want to use to present the content of my site. Obviously, I could use more zpts to hold my content, but I don't really like that idea coz I just want to store the 'meat in the sandwich' (of standard_html_header/footer as it was) - zpts seem overkill and potentially a little confusing for naive users. http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZPT.stx#2-90 mentions that this is not appropriate and mentions some alternative content objects. However, it says CMF solves this issue - and I'm not using CMF, so...
I could use DTML Documents, but I don't want the user to be able to write DTML really, and recent posts, coupled with ChrisMcD's 2.6 Edition Zope Book lead me to believe that way lies the dark side.
DTML Methods clearly aren't right. I want properties anyway.
STX - haven't used it but it looks like it could be handy. Still, I want my users to be able to bash out some html when editing.
Files - may be appropriate as they can just store text and can be edited through the ZMI if less than 64KB I believe. Still, if I want to have the index_html zpt present the contents, I'll have to have urls explicitly of the form file/index_html, otherwise I presume I'll just get a file download prompt from my browser.
So, I think I'm left with Folders. If I store my text as a property of a Folder (and adjust my zpt to reflect this), I can have an auto-presenting content object that doesn't require users to remember to slap the bread around their meat (if you know what I mean ;-) ).
Are Folders the content object of choice in this case then, or am I missing something. BTW, I'd rather not have to use objects that aren't bundled zope as I have to fight for every additional product that is installed.
Thoughts anyone?
tim
_______________________________________________ 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 )
-- J. David Ibáñez, http://www.j-david.net Software Engineer / Ingénieur Logiciel / Ingeniero de Software
Tim Hicks wrote:
STX - haven't used it but it looks like it could be handy. Still, I want my users to be able to bash out some html when editing.
have a look at StructuredDocument => http://www.zope.org/Members/mjablonski
So, I think I'm left with Folders. If I store my text as a property of a Folder (and adjust my zpt to reflect this), I can have an auto-presenting content object that doesn't require users to remember to slap the bread around their meat (if you know what I mean ;-) ).
Are Folders the content object of choice in this case then, or am I missing something. BTW, I'd rather not have to use objects that aren't bundled zope as I have to fight for every additional product that is installed.
maybe you should look at AbracadabraObject => http://www.zope.org/Members/mjablonski I will release an additional generic content object for Abracadbra next week... then your dreams will be fulfilled...;-) cheers, maik -- Maik Jablonski __o www.zfl.uni-bielefeld.de _ \<_ Deutsche Zope User Group Bielefeld, Germany (_)/(_) www.dzug.org
Tim Hicks wrote:
STX - haven't used it but it looks like it could be handy. Still, I want my users to be able to bash out some html when editing.
have a look at StructuredDocument => http://www.zope.org/Members/mjablonski
This looks *very* cool. Don't suppose you have a ZPT ready version? Perhaps having a property on each object to tell it which zpt to try to acquire would be useful?
So, I think I'm left with Folders. If I store my text as a property of a Folder (and adjust my zpt to reflect this), I can have an auto-presenting content object that doesn't require users to remember to slap the bread around their meat (if you know what I mean ;-) ).
Are Folders the content object of choice in this case then, or am I missing something. BTW, I'd rather not have to use objects that aren't bundled zope as I have to fight for every additional product that is installed.
maybe you should look at AbracadabraObject => http://www.zope.org/Members/mjablonski
I will release an additional generic content object for Abracadbra next week... then your dreams will be fulfilled...;-)
Ooh ooh, tell me more :-). What does this content object provide? cheers, tim
Tim Hicks wrote:
Tim Hicks wrote:
STX - haven't used it but it looks like it could be handy. Still, I want my users to be able to bash out some html when editing.
have a look at StructuredDocument =>
http://www.zope.org/Members/mjablonski
This looks *very* cool. Don't suppose you have a ZPT ready version? Perhaps having a property on each object to tell it which zpt to try to acquire would be useful?
maybe I should pack one... I'll think over it...;-)
I will release an additional generic content object for Abracadbra next week... then your dreams will be fulfilled...;-)
It's called PropertyObject. It is a simple, configurable PropertySheet [like you know it from a DTML Document]. The PropertyObject-Manager can set up the sheet, then lock the properties and enter a template for rendering the sheet. Works great with Abracadabra and is very,very useful. I can send you an pre-release off-list if you like. cheers, maik -- Maik Jablonski __o www.zfl.uni-bielefeld.de _ \<_ Deutsche Zope User Group Bielefeld, Germany (_)/(_) www.dzug.org
participants (6)
-
Evan Simpson -
Juan David Ibáñez Palomar -
Maik Jablonski -
Oliver Bleutgen -
Paul Winkler -
Tim Hicks