Re: [Zope] zpt, metal and missing content objects (bit long)
... what if I want to make some global changes to my site? What if I want to add a heading (on every page) right after my <body> tag, and I want it to be the title of the zpt (not 'standard_template', but that using it). Doing the following doesn't seem to work when put in 'standard_template' as 'here' is not what I want when being accessed within a macro.
<body> <h1 tal:content="here/title">title inserted here</h1>
You could use tal:content="template/title" if you want to get the title of the template. here/title will give you the title of the folder containing the template.
Duncan, thanks *very* much. I thought things must be a little simpler than they seemed. This works nicely. So, with that little issue overcome, I guess the only thing I'm left wondering is why my content objects need to contain any explicit use of zpt *within their source* (as opposed to as a property on the object). Using only standard zope objects, the only ways I can see of overcoming this require nasty url mangling that locks me into a specific site system (due to embedded links). By this I mean, if I want to have a zpt called as a method of my object when it's rendered, I could do one of: /render?id=content_object /content_object/view where 'render' is some sort of script that does something like standard_template.__of__(content_object) and where view is an alias to 'standard_template'. How do other people deal with this, or do you just live with having zpt in your content source? cheers, tim
At 15:23 Uhr +0100 12.09.2002, Tim Hicks wrote:
So, with that little issue overcome, I guess the only thing I'm left wondering is why my content objects need to contain any explicit use of zpt *within their source* (as opposed to as a property on the object). Using only standard zope objects, the only ways I can see of overcoming this require nasty url mangling that locks me into a specific site system (due to embedded links). By this I mean, if I want to have a zpt called as a method of my object when it's rendered, I could do one of:
/render?id=content_object /content_object/view
where 'render' is some sort of script that does something like standard_template.__of__(content_object) and where view is an alias to 'standard_template'.
No, you don't need such things. All objects in Zope, that need this, have their own view method... folderish objects on the other hand, look for an index_html for default. This way you can achieve the rendering of an object (a folder is an object, too) using the given template. This idea is abit difficult to grap at first and is quite different from what other AppServers do! Did you have a look at the Zope Book (http://www.zope.org/Documentation/Books/ZopeBook/current), especially the part on acquisition and ZPT already? You need to graps the idea of acquisition, first... You would _not_ use a zpt as a content object! A ZPT is a template for viewing content. It holds placeholders where your content is put in. Your content would be stored in specialised objects that fit your needs for that. those objects hold the content usually in properties. You are right, there is no Basic-Zope object besides fodler that work this way :-( But you can experiment further with more objects. I guess the best way for you would be to create a ZClass. In it you can define the properties that make up your content and you can define the view- and edit-methods needed, even based on ZPT, but you probably need to learn some more things first ;-) Regards Jochen
Jochen, thanks for your reply. See response in line below.
At 15:23 Uhr +0100 12.09.2002, Tim Hicks wrote:
So, with that little issue overcome, I guess the only thing I'm left wondering is why my content objects need to contain any explicit use of zpt *within their source* (as opposed to as a property on the object). Using only standard zope objects, the only ways I can see of overcoming this require nasty url mangling that locks me into a specific site system (due to embedded links). By this I mean, if I want to have a zpt called as a method of my object when it's rendered, I could do one of:
/render?id=content_object /content_object/view
where 'render' is some sort of script that does something like standard_template.__of__(content_object) and where view is an alias to 'standard_template'.
No, you don't need such things. All objects in Zope, that need this, have their own view method... folderish objects on the other hand, look for an index_html for default. This way you can achieve the rendering of an object (a folder is an object, too) using the given template.
I know what you are saying here. 'All objects in Zope, that need this, have their own view method' - well, I want to be able to define the view method, but I don't think I can without one of the two schemes I detailed above.
This idea is abit difficult to grap at first and is quite different from what other AppServers do!
Did you have a look at the Zope Book (http://www.zope.org/Documentation/Books/ZopeBook/current), especially the part on acquisition and ZPT already? You need to graps the idea of acquisition, first...
I have seen this (and while I don't claim to have read it all - or even remembered all I've read), but I still seem to be coming up against this issue of content.
You would _not_ use a zpt as a content object! A ZPT is a template for viewing content. It holds placeholders where your content is put in. Your content would be stored in specialised objects that fit your needs for that. those objects hold the content usually in properties.
I think we agree here, ZPT is _not_ a content object. It seems to be a very good way of templating actual content objects. My problem is apparently a lack of a 'specialised object' that fits my needs. This seems surprising given that all I want to do is store html fragments and sandwich them with standard headers and footers. I would have thought this was a very common use case.
You are right, there is no Basic-Zope object besides fodler that work this way :-( But you can experiment further with more objects.
I realise that Folders could be used, but this is fairly unattractive to me as it would make a bit of a mess of the ZMI tree, seem rather unintuitive to naive users ("how can the page be a folder?") and because they do not provide the sort of easy TTW editing interface that DTML Documents / ZPTs and the like have in the ZMI. I have experimented with other objects (both standard zope and third party - including my own). Given my current requirements are for an object from the base zope install (which is looking increasingly unlikely to fit with what I want), the best I could find was the 'File' object. For plain text under 64KB (I think), they provide nice textarea editing (well, as nice as that can be ;-) ) in the zmi. Evan Simpson posted a method whereby I could use a mixture of 'Folders' and 'Files' to get around my default view method problem (http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/E56D8933FDE6BDA2 ). This would work, but seems like a hack to me and leaves me with a folder and a file for every logical content object :-(, and to some extent, similar issues to what I had with just using Folders as content objects. This still seems like a better solution to me though, and may be what I do for now in the knowledge that it should be fairly easy to produce a script to convert this messy folder structure into something more coherent in the future.
I guess the best way for you would be to create a ZClass. In it you can define the properties that make up your content and you can define the view- and edit-methods needed, even based on ZPT, but you probably need to learn some more things first ;-)
I'm stearing clear of ZClasses after getting my fingers slightly burnt and reading other posts regarding them. Even if that weren't the case, I can't use custom products (be they zclass or python) in this project as I can't get them onto the zope instance I must use :-(. thanks again for your reply. tim
Hi Tim, given, that your html fragments _really_ are the content and not part of the presentation (for example because you're working on a Site on "best practice HTML") and no other object types than the basic ones you're right, there's no document that fits. If CMF was an option, that holds several content-types that would _exactly_ fit your need... Doing a ZClass for what you need should not be too tricky, as it just should hold properties, no special functionality... But nevertheless, from your original post I replied to, I still have the feeling you might not have the correct notion how some things in Zope work... Jochen At 17:50 Uhr +0100 12.09.2002, Tim Hicks wrote:
Jochen,
thanks for your reply. See response in line below.
At 15:23 Uhr +0100 12.09.2002, Tim Hicks wrote:
So, with that little issue overcome, I guess the only thing I'm left wondering is why my content objects need to contain any explicit use of zpt *within their source* (as opposed to as a property on the object). Using only standard zope objects, the only ways I can see of overcoming this require nasty url mangling that locks me into a specific site system (due to embedded links). By this I mean, if I want to have a zpt called as a method of my object when it's rendered, I could do one of:
/render?id=content_object /content_object/view
where 'render' is some sort of script that does something like standard_template.__of__(content_object) and where view is an alias to 'standard_template'.
No, you don't need such things. All objects in Zope, that need this, have their own view method... folderish objects on the other hand, look for an index_html for default. This way you can achieve the rendering of an object (a folder is an object, too) using the given template.
I know what you are saying here. 'All objects in Zope, that need this, have their own view method' - well, I want to be able to define the view method, but I don't think I can without one of the two schemes I detailed above.
This idea is abit difficult to grap at first and is quite different from what other AppServers do!
Did you have a look at the Zope Book (http://www.zope.org/Documentation/Books/ZopeBook/current), especially the part on acquisition and ZPT already? You need to graps the idea of acquisition, first...
I have seen this (and while I don't claim to have read it all - or even remembered all I've read), but I still seem to be coming up against this issue of content.
You would _not_ use a zpt as a content object! A ZPT is a template for viewing content. It holds placeholders where your content is put in. Your content would be stored in specialised objects that fit your needs for that. those objects hold the content usually in properties.
I think we agree here, ZPT is _not_ a content object. It seems to be a very good way of templating actual content objects. My problem is apparently a lack of a 'specialised object' that fits my needs. This seems surprising given that all I want to do is store html fragments and sandwich them with standard headers and footers. I would have thought this was a very common use case.
You are right, there is no Basic-Zope object besides fodler that work this way :-( But you can experiment further with more objects.
I realise that Folders could be used, but this is fairly unattractive to me as it would make a bit of a mess of the ZMI tree, seem rather unintuitive to naive users ("how can the page be a folder?") and because they do not provide the sort of easy TTW editing interface that DTML Documents / ZPTs and the like have in the ZMI.
I have experimented with other objects (both standard zope and third party - including my own). Given my current requirements are for an object from the base zope install (which is looking increasingly unlikely to fit with what I want), the best I could find was the 'File' object. For plain text under 64KB (I think), they provide nice textarea editing (well, as nice as that can be ;-) ) in the zmi. Evan Simpson posted a method whereby I could use a mixture of 'Folders' and 'Files' to get around my default view method problem (http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/E56D8933FDE6BDA2 ). This would work, but seems like a hack to me and leaves me with a folder and a file for every logical content object :-(, and to some extent, similar issues to what I had with just using Folders as content objects. This still seems like a better solution to me though, and may be what I do for now in the knowledge that it should be fairly easy to produce a script to convert this messy folder structure into something more coherent in the future.
I guess the best way for you would be to create a ZClass. In it you can define the properties that make up your content and you can define the view- and edit-methods needed, even based on ZPT, but you probably need to learn some more things first ;-)
I'm stearing clear of ZClasses after getting my fingers slightly burnt and reading other posts regarding them. Even if that weren't the case, I can't use custom products (be they zclass or python) in this project as I can't get them onto the zope instance I must use :-(.
thanks again for your reply.
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 )
Hi Tim,
given, that your html fragments _really_ are the content and not part of the presentation (for example because you're working on a Site on "best practice HTML") and no other object types than the basic ones you're right, there's no document that fits.
I'm not working on a site on 'best practice HTML' ;-). I simply need to present many pages to viewers with a consistent look-and-feel. The pages need only be available in html (as opposed to anything else like pdf, wml, or whatever), so I don't need to store XML or some other more data oriented format that must be converted to html. I also have access to rather a nice ttw java applet for editing this html content in a wysiwyg way. Storing html fragments (i.e. those that can't be abstracted out into the header/footer because they change from page to page) seems to be the way to go... but then I'm coming from the <dtml-var standard_html_header/footer> way of doing things. Given this, do you have any other ideas for a setup?
If CMF was an option, that holds several content-types that would _exactly_ fit your need...
I don't have access to CMF on the production server.
Doing a ZClass for what you need should not be too tricky, as it just should hold properties, no special functionality...
It's still not a runner.
But nevertheless, from your original post I replied to, I still have the feeling you might not have the correct notion how some things in Zope work...
I'm sure you're right there, but could you elaborate so I might see how others use zope? cheers, tim
Jochen
At 17:50 Uhr +0100 12.09.2002, Tim Hicks wrote:
Jochen,
thanks for your reply. See response in line below.
At 15:23 Uhr +0100 12.09.2002, Tim Hicks wrote:
So, with that little issue overcome, I guess the only thing I'm left wondering is why my content objects need to contain any explicit use of zpt *within their source* (as opposed to as a property on the object). Using only standard zope objects, the only ways I can see of overcoming this require nasty url mangling that locks me into a specific site system (due to embedded links). By this I mean, if I want to have a zpt called as a method of my object when it's rendered, I could do one of:
/render?id=content_object /content_object/view
where 'render' is some sort of script that does something like standard_template.__of__(content_object) and where view is an alias to 'standard_template'.
No, you don't need such things. All objects in Zope, that need this, have their own view method... folderish objects on the other hand, look for an index_html for default. This way you can achieve the rendering of an object (a folder is an object, too) using the given template.
I know what you are saying here. 'All objects in Zope, that need this, have their own view method' - well, I want to be able to define the view method, but I don't think I can without one of the two schemes I detailed above.
This idea is abit difficult to grap at first and is quite different from what other AppServers do!
Did you have a look at the Zope Book (http://www.zope.org/Documentation/Books/ZopeBook/current), especially the part on acquisition and ZPT already? You need to graps the idea of acquisition, first...
I have seen this (and while I don't claim to have read it all - or even remembered all I've read), but I still seem to be coming up against this issue of content.
You would _not_ use a zpt as a content object! A ZPT is a template for viewing content. It holds placeholders where your content is put in. Your content would be stored in specialised objects that fit your needs for that. those objects hold the content usually in properties.
I think we agree here, ZPT is _not_ a content object. It seems to be a very good way of templating actual content objects. My problem is apparently a lack of a 'specialised object' that fits my needs. This seems surprising given that all I want to do is store html fragments and sandwich them with standard headers and footers. I would have thought this was a very common use case.
You are right, there is no Basic-Zope object besides fodler that work this way :-( But you can experiment further with more objects.
I realise that Folders could be used, but this is fairly unattractive to me as it would make a bit of a mess of the ZMI tree, seem rather unintuitive to naive users ("how can the page be a folder?") and because they do not provide the sort of easy TTW editing interface that DTML Documents / ZPTs and the like have in the ZMI.
I have experimented with other objects (both standard zope and third party - including my own). Given my current requirements are for an object from the base zope install (which is looking increasingly unlikely to fit with what I want), the best I could find was the 'File' object. For plain text under 64KB (I think), they provide nice textarea editing (well, as nice as that can be ;-) ) in the zmi. Evan Simpson posted a method whereby I could use a mixture of 'Folders' and 'Files' to get around my default view method problem
(http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/E56D8933FDE6BDA 2
). This would work, but seems like a hack to me and leaves me with a folder and a file for every logical content object :-(, and to some extent, similar issues to what I had with just using Folders as content objects. This still seems like a better solution to me though, and may be what I do for now in the knowledge that it should be fairly easy to produce a script to convert this messy folder structure into something more coherent in the future.
I guess the best way for you would be to create a ZClass. In it you can define the properties that make up your content and you can define the view- and edit-methods needed, even based on ZPT, but you probably need to learn some more things first ;-)
I'm stearing clear of ZClasses after getting my fingers slightly burnt and reading other posts regarding them. Even if that weren't the case, I can't use custom products (be they zclass or python) in this project as I can't get them onto the zope instance I must use :-(.
thanks again for your reply.
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 )
At 19:02 Uhr +0100 12.09.2002, Tim Hicks wrote:
given, that your html fragments _really_ are the content and not part of the presentation (for example because you're working on a Site on "best practice HTML") and no other object types than the basic ones you're right, there's no document that fits.
I'm not working on a site on 'best practice HTML' ;-). I simply need to present many pages to viewers with a consistent look-and-feel.
Well, you should not do it that way, I guess. Given you have many similar pages you can probably identify common properties. Take those out and put them in object properties. If you just want to do a basically static site but with a common look an feel, you could use PageTemplates. The common parts would be put into the mass of your pages with metal:macros. But the start of our discussion was to seperate template from content so we're not really getting anywhere here...
The pages need only be available in html (as opposed to anything else like pdf, wml, or whatever), so I don't need to store XML or some other more data oriented format that must be converted to html. I also have access to rather a nice ttw java applet for editing this html content in a wysiwyg way. Storing html fragments (i.e. those that can't be abstracted out into the header/footer because they change from page to page) seems to be the way to go... but then I'm coming from the <dtml-var standard_html_header/footer> way of doing things.
Given this, do you have any other ideas for a setup?
If CMF was an option, that holds several content-types that would _exactly_ fit your need...
I don't have access to CMF on the production server.
Could you please explain what kind of a beast this Zope is that you will be using??? Jochen
Jochen,
At 19:02 Uhr +0100 12.09.2002, Tim Hicks wrote:
given, that your html fragments _really_ are the content and not part of the presentation (for example because you're working on a Site on "best practice HTML") and no other object types than the basic ones you're right, there's no document that fits.
I'm not working on a site on 'best practice HTML' ;-). I simply need to present many pages to viewers with a consistent look-and-feel.
Well, you should not do it that way, I guess. Given you have many similar pages you can probably identify common properties. Take those out and put them in object properties.
This seems like over-complexity for this case. It would make it far more complicated to use my java ttw html editing widget. I think I understand the idea of having properties on objects and building pages dynamically, it's just in this case, it seems that I only really want one property, and that consists of html content.
If you just want to do a basically static site but with a common look an feel, you could use PageTemplates. The common parts would be put into the mass of your pages with metal:macros. But the start of our discussion was to seperate template from content so we're not really getting anywhere here...
That's still what I'm talking about, it's just my content happens to already be html. I have no need or desire to break it down into separate properties on a folder for it to simply be reconstructed on rendering into the exact same form as it was generated in. In this project (and in many others I am/have been involved in), all I want is a content object that renders with a standard look-and-feel (i.e. a header and a footer), but that doesn't require explicitly embedding this look-and-feel code into the actual content (this is what I mean by separating template and content, in this case). Products such as StructuredDocument and HTMLDocument do this, but use dtml headers, whereas I want to use zpt for my templating. I think this is a common use case, and find it surprising that there isn't a built-in (to zope) solution for this.
The pages need only be available in html (as opposed to anything else like pdf, wml, or whatever), so I don't need to store XML or some other more data oriented format that must be converted to html. I also have access to rather a nice ttw java applet for editing this html content in a wysiwyg way. Storing html fragments (i.e. those that can't be abstracted out into the header/footer because they change from page to page) seems to be the way to go... but then I'm coming from the <dtml-var standard_html_header/footer> way of doing things.
Given this, do you have any other ideas for a setup?
If CMF was an option, that holds several content-types that would _exactly_ fit your need...
I don't have access to CMF on the production server.
Could you please explain what kind of a beast this Zope is that you will be using???
It's Zope 2.5.1 with BTreeFolder, HTMLDocument, PhotoFolder, ExtFile/ExtImage and ZUBB as additional products. I do not control the server, and cannot get any more products onto it. all the best, tim
All, just thought I'd post a follow-up to my previous rants/deliberations regarding content objects and zpts. Thanks to Jochen and Paul pointing me in the direction of 'Folders', I now seem to have a rather easy to use, flexible and manageable site setup. I was sceptical about using Folders at first as I thought they'd: o confuse my users - "so the folders are the web pages??!!"; o clutter the ZMI - every content object appearing as a leaf in the left-hand tree; o be unwieldy to use within the ZMI due to them not having textareas for editing (without going into the 'Properties' tab). I think I still stand by these problems, but they are easily circumvented by using custom management screens to take out some of the more confusing aspects of the setup. This is what I've done.
From reading the blurb about 'Kubes', I think I've essentially implemented a poor-man's version. Instead of defining a new class in a product (non-standard products were not available to me for this project remember), I simply wrote custom management methods (as python scripts) that added/edited properties to allow me to distinguish between certain object types as I needed.
An unexpected added bonus was the easy way I can switch from content being just a text property (i.e. static html), to dynamically scripted using zpt/dtml/whatever. All I need to do is define a subobject on my folder (with the name I've chosen for content - 'content'). The index_html acquired from the site root simply inserts the rendered result of the context's 'content' attribute and all works nicely. The only thing I'm missing now is catalogawareness, although I suppose I could even hack that functionality into my customised edit methods. I'm a little leery of this approach as any time people use the ZMI (and some inevitably will at some stage), the catalog becomes out of sync. It just feels too hacky. Anyway, I'm off to install 'Kubes', figure out how to make them catalogaware, figure out if their content can be easily turned into scripts and double check that they solve the ZMI issues in this sort of setup. For now though, I'm a happy bunny. I've got a solution that I like where before, things were looking a little dicey. cheers, tim
Tim, You've done a pretty good job of ruling out all your options. ;-) Comments inline... On Thu, Sep 12, 2002 at 05:50:23PM +0100, Tim Hicks wrote:
At 15:23 Uhr +0100 12.09.2002, Tim Hicks wrote:
So, with that little issue overcome, I guess the only thing I'm left wondering is why my content objects need to contain any explicit use of zpt *within their source* (as opposed to as a property on the object). Using only standard zope objects, the only ways I can see of overcoming this require nasty url mangling that locks me into a specific site system (due to embedded links). By this I mean, if I want to have a zpt called as a method of my object when it's rendered, I could do one of:
/render?id=content_object /content_object/view
The former, IMHO, is really ugly and will only get worse as your site gets more complex. I've done the latter in a recent case that involved putting the same content object (a custom Product) into two different views in different places, when I didn't have the luxury of building the context from the ground up but had to fit the views into two very different existing template systems. So I just created two different "view" methods, and I can get the right one just by calling a URL that acquires the appropriate view. I'm not too worried about "locking into a specific site system", because all the URLs that do this are automatically generated in a few navigation methods, so I can just modify those if need be. With all that said, I think you might reconsider your objections to using Folders:
No, you don't need such things. All objects in Zope, that need this, have their own view method... folderish objects on the other hand, look for an index_html for default. This way you can achieve the rendering of an object (a folder is an object, too) using the given template.
So: topfolder/+-index_html | +-subfolder1/+-content | +-subfolder2/+-content Then index_html can be something like: <html> <head><title tal:content="here/title"> or maybe you want template/title? </title></head> <body> <div tal:replace="here/content | nothing"> content goes here </div> </body> </html>
I know what you are saying here. 'All objects in Zope, that need this, have their own view method' - well, I want to be able to define the view method, but I don't think I can without one of the two schemes I detailed above.
Yes you can: either use custom products, which you say are off-limits for this project, or use index_html on folders.
I think we agree here, ZPT is _not_ a content object. It seems to be a very good way of templating actual content objects. My problem is apparently a lack of a 'specialised object' that fits my needs.
I'm telling you man, folders... :)
You are right, there is no Basic-Zope object besides fodler that work this way :-( But you can experiment further with more objects.
I realise that Folders could be used, but this is fairly unattractive to me as it would make a bit of a mess of the ZMI tree, seem rather unintuitive to naive users ("how can the page be a folder?") and because they do not provide the sort of easy TTW editing interface that DTML Documents / ZPTs and the like have in the ZMI.
I understand these objections, but think you've exhausted the alternatives that don't involve creating or installing products, and IMHO folders are probably the best approach. I can relate, I've faced similar issues; but sooner or later you'll have to stop painting yourself into a corner and pick one of these solutions.
I have experimented with other objects (both standard zope and third party - including my own). Given my current requirements are for an object from the base zope install (which is looking increasingly unlikely to fit with what I want), the best I could find was the 'File' object. For plain text under 64KB (I think), they provide nice textarea editing (well, as nice as that can be ;-) ) in the zmi. Evan Simpson posted a method whereby I could use a mixture of 'Folders' and 'Files' to get around my default view method problem (http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/E56D8933FDE6BDA2 ). This would work, but seems like a hack to me and leaves me with a folder and a file for every logical content object :-(
True, but here we go again - there is no standard zope object that does what you want. And it'll seem less strange if your requirements expand such that other elements of the presentation may change, or the content wants to be in more than one file. Example: topfolder/+-index_html +-navigation_bar +-image1.gif | +-subfolder1/+-content | +-subfolder2/+-content | +-image1.gif | +-subfolder3/+-content +-navigation_bar We've still got one master template, but we've got localized changes: if we view subfolder2, we get a different image; if we view subfolder3, we get a different navigation bar. As sites get more complex, it gets really nice to be able to break these things out from index_html and structure both your presentation and your content more logically. -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
Paul,
You've done a pretty good job of ruling out all your options. ;-)
I was starting to realise that ;-). I think I was hoping someone was going to come in and tell me something obvious that fixed all my problems :-).
/render?id=content_object /content_object/view
The former, IMHO, is really ugly and will only get worse as your site gets more complex.
I've done the latter in a recent case that involved putting the same content object (a custom Product) into two different views in different places, when I didn't have the luxury of building the context from the ground up but had to fit the views into two very different existing template systems.
So I just created two different "view" methods, and I can get the right one just by calling a URL that acquires the appropriate view.
I'm not too worried about "locking into a specific site system", because all the URLs that do this are automatically generated in a few navigation methods, so I can just modify those if need be.
This got me thinking. "I can get the right one just by calling a URL that acquires the appropriate view." - by this I presume you mean you have your two views (say 'view1' and 'view2') as objects at the root of your site, but you still must append /viewX to the url to get the appropriate one. I'm not mad keen on forcing the /viewX to be appended because, while navigational links are constructed automatically, (naive) users will be editing content and embedding links into it. Then, I have the twin problem of getting them to remember to append /view on all their links, and hard-coded links in this format making it difficult to change. But!! I thought, how's about I force the view further up in the url. So, while my structure is actually /site/foo/bar.html, my url would look like /site/new/foo/bar.html. 'new' is a python script that traps the traverse_subpath and does the following: ---- import string physPath = list(context.getPhysicalPath()) path = string.join(physPath+traverse_subpath, '/') + '/content_template' ob = container.restrictedTraverse(path) print ob(context, context.REQUEST) return printed ---- Just in case the url in the browser stops on a folder and not a file, I've added a script in /site called 'document_src' looking like: ---- return context['index_html'].document_src() ---- I've verified that this works, although I haven't tested with things like images etc (although I'm sure I could make the 'new' script flexible enough to deal with whatever I need for this site). I'm just not sure if there are any security, performance or any other issues with such a setup. It does seem slightly convoluted to me. Do you (or anybody else) have any views on this?
With all that said, I think you might reconsider your objections to using Folders:
<snipped lots of interesting Folder chat> Ok, you've partially brought me round to the benefits of folders ;-). My choice now appears to be between the system outlined above, and 'folders man' ;-). Any comments on relative merits would be greatly appreciated. Thanks very much for your post, it was really useful. And yes, I know, I've got to stop moaning at some point and actually do something ;-). cheers, tim
On Thu, Sep 12, 2002 at 09:56:56PM +0100, Tim Hicks wrote:
Paul,
You've done a pretty good job of ruling out all your options. ;-)
I was starting to realise that ;-). I think I was hoping someone was going to come in and tell me something obvious that fixed all my problems :-).
Me too, secretly :)
I'm not too worried about "locking into a specific site system", because all the URLs that do this are automatically generated in a few navigation methods, so I can just modify those if need be.
This got me thinking. "I can get the right one just by calling a URL that acquires the appropriate view." - by this I presume you mean you have your two views (say 'view1' and 'view2') as objects at the root of your site, but you still must append /viewX to the url to get the appropriate one.
Close, but it's not view1 and view2, it's just view. I've got something like: /site1/view /site2/view /shared/ (content objects go here) To view a content object foo, a proper URL would be /site1/shared/foo/view or /site2/shared/foo/view This way, I get a different view of the same content, depending on the context; and the URLs are identical except for the leading context, which makes managing the navigation code easier. Yes, it's annoying to have /view on the end of everything, but /site1 and /site2 were built before I got here and my requirements were "get this shared content to fit into the presentation of both these sites, ASAP."
I'm not mad keen on forcing the /viewX to be appended because, while navigational links are constructed automatically, (naive) users will be editing content and embedding links into it. Then, I have the twin problem of getting them to remember to append /view on all their links, and hard-coded links in this format making it difficult to change.
Yeah, that is annoying.
But!! I thought, how's about I force the view further up in the url.
(snip)
I'm just not sure if there are any security, performance or any other issues with such a setup. It does seem slightly convoluted to me. Do you (or anybody else) have any views on this?
Security? No idea. Performance? Considering the amount of acquisition magic that happens on a typical zope site, probably not a worry. Convoluted? A bit. I'd want to test this really, really thoroughly before going live with it. Acquisition is hard enough to understand without customizing it. :-/
Ok, you've partially brought me round to the benefits of folders ;-). My choice now appears to be between the system outlined above, and 'folders man' ;-). Any comments on relative merits would be greatly appreciated.
The folders approach doesn't do any magic that's not standard zope, so it's easier to be sure it works. OTOH, I understand the interface concerns. It's really too bad you can't add custom products; that would let you do exactly what you want. I would recommend zclasses, except that I won't touch zclasses. :-} I've made my folderish objects easier to work with by presenting a custom interface, which is a lot more luser-proof (he said as he contemplated writing a script to rename a couple hundred images with spaces in their IDs). --PW Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
participants (3)
-
Jochen Haeberle -
Paul Winkler -
Tim Hicks