Re: [Zope] Help needed for a s(i|a)mple site
Hi,
I thought I could acquire the Zen by readings the docs, following the list and just doing it, but I'm afraid I have to ask for some guidance. Please bear with me. I'd be glad if I would get at least a few hints, thanks in advance.
I'm trying to set up a simple (sample?) Zope site, and thought I should try and use ZClasses.
What you're doing isn't normally done with ZClasses. Chances are, you can do what you'd like much easier by using DTML Methods in the root and acquiring them in subfolders. Since this isn't a production site, I'll assume you're using ZClasses just as an exercise. There are a couple caveats when using ZClasses. (If these have been corrected when I wasn't looking, hopefully someone will correct me.) A ZClass cannot be the index_html of a Folder. You can call it that, but it won't work. What you _could_ do is put an index_html document in your SFolder class, which looks for an SPage called 'index_spage' or some such thing and renders it. That would also allow you to manage your headers and footers and whatnot from outside your content SPages. Do try to follow the convention of using standard_html_header and _footer. With this little scheme, the index_html method you end up with in your ZPage would something look like this-- <dtml-var standard_html_header> <dtml-if "objectValues(['SFolder']) <!-- display navigation links --> </dtml-if> <dtml-if index_spage> <dtml-var index_spage> <dtml-else> <dtml-in "objectValues(['SPage'])"> <!-- display available pages --> </dtml-in> </dtml-else> <dtml-var standard_html_footer> As you can see, nothing is happening here that couldn't be done by placing a similar index_html method in your root Zope folder and acquiring it in subfolders. HTH, Mike.
On Fri, Nov 12, 1999 at 08:47:57AM -0500, Mike Pelletier wrote:
What you're doing isn't normally done with ZClasses. Chances are, you can do what you'd like much easier by using DTML Methods in the root and acquiring them in subfolders. Since this isn't a production site, I'll assume you're using ZClasses just as an exercise.
I wanted to use ZClasses since they seemed to be a nice and easy way to customize and limit the user interface (no dozens of products in a folder's "Add" list) for content managers. I think this is how you did Zope.org, not ? In the meantime I managed to set up a product that somehow works like what I described: I have a ZClass SRoot that's derived from a folderish ZClass SFolder, and a ZClass SPage that actually contains the "render engine" for pages (i.e. it contains the code for the navigations bars in customized standard_html_header and _footer methods, and an index_html that currently only renders the property stext as structured text).
<dtml-var standard_html_header>
<dtml-if "objectValues(['SFolder']) <!-- display navigation links --> </dtml-if>
<dtml-if index_spage> <dtml-var index_spage> <dtml-else> <dtml-in "objectValues(['SPage'])"> <!-- display available pages --> </dtml-in> </dtml-else>
<dtml-var standard_html_footer>
That's not exactly what I wanted to have: I need a SRoot (well, could have used the site root, but this way it's more flexible), since my SFolder navigation bar should alway display all folders from the site's root on (just like the tree tag).
As you can see, nothing is happening here that couldn't be done by placing a similar index_html method in your root Zope folder and acquiring it in subfolders.
But without ZClasses, I wouldn't be able to customize the user experience for content editors the way you did in Zope.org, would I ? I'm still struggling with one problem: Every SFolder should contain at least one SPage (let's call it index_spage). How can I have that subobject be added to any SFolder object ? If I try to add an SPage object to my SFolderClass, I get an AttributeError from Zope (using 2.1.0beta1): <!-- Error type: AttributeError Error value: spage_properties --> <!-- Traceback (innermost last): File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 252, in publish_module File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 207, in publish File /usr/lib/zope/lib/python/Zope/__init__.py, line 201, in zpublisher_exception_hook (Object: RoleManager) File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 193, in publish File /usr/lib/zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: SPageClass_add) File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 102, in call_object (Object: SPageClass_add) File /usr/lib/zope/lib/python/OFS/DTMLMethod.py, line 145, in __call__ (Object: SPageClass_add) File /usr/lib/zope/lib/python/DocumentTemplate/DT_String.py, line 502, in __call__ (Object: SPageClass_add) File /usr/lib/zope/lib/python/DocumentTemplate/DT_With.py, line 148, in render (Object: SPageClass.createInObjectManager(REQUEST['id'], REQUEST)) File /usr/lib/zope/lib/python/DocumentTemplate/DT_Util.py, line 335, in eval (Object: propertysheets.spage_properties.manage_editProperties(REQUEST)) (Info: REQUEST) File <string>, line 0, in ? File /usr/lib/zope/lib/python/DocumentTemplate/DT_Util.py, line 127, in careful_getattr AttributeError: (see above)
Gregor
<flight@mathi.uni-heidelberg.de> wrote:
I wanted to use ZClasses since they seemed to be a nice and easy way to customize and limit the user interface (no dozens of products in a folder's "Add" list) for content managers. I think this is how you did Zope.org, not ?
Well, yes and no. Our ZClasses package up certain kinds of member contributed content, but typically not where a DTML Document could have been used. ZClasses are not used for the site structure. The site structure is still done with Folders and DTML Methods, which find the ZClasses in the ZCatalog. The only time I can think of where I might advocate using a Folder sub-ZClass instead of actual Folders is if you wanted to provide a simplified management interface to content managers, but even then I'd only do this if the content managers were the general public such as for a Geocities type situation. Zope.org does not do this. I'm certainly not saying "Don't do this" though. Just be aware that ZClasses still have a wild-frontiersy feel, and this is likely to be the more difficult route.
But without ZClasses, I wouldn't be able to customize the user experience for content editors the way you did in Zope.org, would I ?
I don't understand what you say here. What is meant by "customize the [content managers's] experience"? Members still see the standard Folder management interface, and 'flat' content is still mostly done with DTML Methods and Documents. Things like News Items, Links, etc, which we want to have additional behaviour are ZClasses.
I'm still struggling with one problem: Every SFolder should contain at least one SPage (let's call it index_spage). How can I have that subobject be added to any SFolder object ? If I try to add an SPage object to my SFolderClass, I get an AttributeError from Zope (using 2.1.0beta1):
Add programatically it from the manage_addSPage method. If you add it directly to your folderish ZClass, all SFolders will share a single SPage. Mike.
On Fri, Nov 12, 1999 at 10:17:43AM -0500, Mike Pelletier wrote:
<flight@mathi.uni-heidelberg.de> wrote:
But without ZClasses, I wouldn't be able to customize the user experience for content editors the way you did in Zope.org, would I ?
I don't understand what you say here. What is meant by "customize the [content managers's] experience"? Members still see the standard Folder management interface, and 'flat' content is still mostly done with DTML Methods and Documents. Things like News Items, Links, etc, which we want to have additional behaviour are ZClasses.
Uuups, I see. Zope.org's member interface looks so clean only since there are only one or two products installed. I'm used to my menu with dozens of products, and that's not exactly what I wanted every user to be confronted with. Now imagine you'd install a few more products to Zope org. All of them would be listed in the member's user interface, too. If you would run multiple Zope instances on one machine, each instance would list all products that any single instance makes use of. But okay, Zope user interface, that's a different story. I got your point here. Gregor
Uuups, I see. Zope.org's member interface looks so clean only since there are only one or two products installed. I'm used to my menu with dozens of products, and that's not exactly what I wanted every user to be confronted with. Now imagine you'd install a few more products to Zope org. All of them would be listed in the member's user interface, too. If you would run multiple Zope instances on one machine, each instance would list all products that any single instance makes use of.
You can control what your content managers see on the Add list by giving them a unique roll and then hand-picking the objects that roll is permitted to Add. Mike.
I would not include standard_html_* in the ZClass itself, because than you can only modify it for the hole site and not per hierarchy. This would make the system very static and does not allow a great deal of flexibility. Another way would be if the standard_html* pages include itself acquired documents and would only fall back to class defaults, if there is no document in the aquistion path. Just ideas... __Janko
participants (3)
-
flight＠mathi.uni-heidelberg.de -
Janko Hauser -
Mike Pelletier