Page Templates are great, but...
I like page templates because they permit uncomplicated cooperation with designers who don't know DTML and/or use drag-and-drop composers. Newbie I am, however, I see a few problems here, and I hope they stem from my ignorance. 1.) Can page templates be "modularized"? DTML is great for assembling pages from re-usable blocks, i.e. dtml_standard_header, dtml_standard_footer. I have not found an equivalent facility for page templates. Is there any? 2.) Symbols How am I supposed to work with symbolic information like table width? Of course, I'm free to create python-functions which pull the raw figures from a config-file or db, but having a separate function for each of the dozens of symbols I would need will give me carpal tunnel syndrome. 3.) Dynamic pages This is a more generic newbie question, since it is not confined to the realms of page templates. Let's say my site sports a uniform layout for hundreds of used-car ads. Each ad gets its own page which content is pulled from a data-base on the fly. This content is wrapped into identical hooks for banner ads, a header, footer and navigation bar. Without Zope one sets up a table of content with a link to each ad; each link calls a cgi-script with some id for the data-base in the QUERY_STRING. This requires the script to assemble the page, send the cgi-ahoy (content-type: text/blabla) and the <html> for the page. Is there a Zope-ish way to do this? I have not even found a way to access a page template from a script for reading. The data for Zope-objects seems to be pickled in files.db. Thanks page ______________________________________________________________________ Do you want a free e-mail for life ? Get it at http://www.hotmail.ro/
On Sun, 2002-06-02 at 08:36, Page Page wrote:
I like page templates because they permit uncomplicated cooperation with designers who don't know DTML and/or use drag-and-drop composers. Newbie I am, however, I see a few problems here, and I hope they stem from my ignorance.
1.) Can page templates be "modularized"? DTML is great for assembling pages from re-usable blocks, i.e. dtml_standard_header, dtml_standard_footer. I have not found an equivalent facility for page templates. Is there any?
There seems to be two ways to manage this stuff. Metal is great, but will push you into building "well-formed" modules - so instead of standard_header and standard_footer, you build a standard_page macro, which contains both, and feed your content into that. It's a bit wierd, but it works well. Alternately, for complete "blocks", you can simply call other ptl from inside your ptl pages. They still have to be well-formed, but that's a nice way to build, for example, a ptl page that renders one particular object (the example I have in my head is from our system, where we have invoices for customers, and we display them in multiple places - so we have a "render_invoice" ptl, that gets called from a few different spots, where-ever we want the invoice to appear). The big trick with all of this is making well-formed pages, even when you're making little snippets - opened tags have to be closed, etc. It just means you need to approach your layout a little differently, is all.
2.) Symbols How am I supposed to work with symbolic information like table width? Of course, I'm free to create python-functions which pull the raw figures from a config-file or db, but having a separate function for each of the dozens of symbols I would need will give me carpal tunnel syndrome.
Not sure what you mean here. You're talking about tal:attributes values, and working out what they should be?
3.) Dynamic pages This is a more generic newbie question, since it is not confined to the realms of page templates. Let's say my site sports a uniform layout for hundreds of used-car ads. Each ad gets its own page which content is pulled from a data-base on the fly. This content is wrapped into identical hooks for banner ads, a header, footer and navigation bar. Without Zope one sets up a table of content with a link to each ad; each link calls a cgi-script with some id for the data-base in the QUERY_STRING. This requires the script to assemble the page, send the cgi-ahoy (content-type: text/blabla) and the <html> for the page. Is there a Zope-ish way to do this? I have not even found a way to access a page template from a script for reading. The data for Zope-objects seems to be pickled in files.db.
Normally, from what you've said above, you'd either: a) keep everything in ptl/zope pages - write a zsql method that uses your zope database adaptor to make the request, call that from a python script or ptl page that wraps the results in html (lots of tal:repeat stuff), feed the whole lot through a macro that wraps it in header/footer banners etc. b) write a python product - said product would know how to talk to the database, pull the appropriate data out, and return it ready to be wrapped up as above. "a" is probably sufficient for what you're looking at, I suspect. "b" adds some complexity that may not be warranted. The basic approach is similar in both cases, however. You'd browse to a page like: http://your.host.com/display/ad?adID=24 /display/ad would take the adID, call another ptl or python script that would call the zsql method to get the ad details, wrap the details in html, then return. /display/ad would pipe the whole lot through a macro that adds banners etc. Sound appropriate? KJL
KevinL wrote:
There seems to be two ways to manage this stuff. Metal is great, but will push you into building "well-formed" modules - so instead of standard_header and standard_footer, you build a standard_page macro, which contains both, and feed your content into that. It's a bit wierd, but it works well.
Please realize that this use of METAL, while a fairly effective way to implement uniform page layouts, is not its primary use! This often seems to be lost on newcomers to ZPT, whose first exposure to METAL is this rather advanced and complex case. The simplest, most straightforward use of METAL is to pull reusable snippets from a library page, or simply from a page that is "typical" of part of your site. Suppose, for example, that the index_html of your site has a copyright notice at the bottom. You can mark this notice for reuse throughout your site without doing the whole page macro dance, like so: <div id="copyright" metal:define-macro="copyright"> This page ©2002 Foobly Enterprises LLC, all rights reserved. </div> Now you reuse it in other pages with: <div metal:use-macro="here/index_html/macros/copyright"></div> No slots or other complications needed. Any TAL in the macro is executed as though it were part of the page that's using it, so you don't need to worry about passing parameters, or losing context, or any of the difficulties introduced by calling one template from another. An addition advantage over <span tal:replace="structure here/zpt_snippet"> is that a single page can define any number of independent macros. Cheers, Evan @ 4-am
On Mon, 2002-06-03 at 05:11, Evan Simpson wrote:
KevinL wrote:
There seems to be two ways to manage this stuff. Metal is great, but will push you into building "well-formed" modules - so instead of standard_header and standard_footer, you build a standard_page macro, which contains both, and feed your content into that. It's a bit wierd, but it works well.
Please realize that this use of METAL, while a fairly effective way to implement uniform page layouts, is not its primary use! This often seems to be lost on newcomers to ZPT, whose first exposure to METAL is this rather advanced and complex case.
I think that's because it's the first thing you want to do. Particularly, migrating from dtml to ptl, the first thing I need to do is take standard_html_header and _footer (and indeed, that whole mindset of "here's where we define a common look/layout for the pages"), and convert them to ptl. I reckon what you're considering as an "advanced and complex case" is actually about the first thing most people need to figure out how to do. Otherwise, you're right back in "build the structure of each page into each page", which is boring and tedious and hard to work with. Am I making sense? Our particular application went one step further, and used slots for primary_content, help_text, error_message, and a few other things - which made site design _so_ much easier (and meant us non-html-coders could throw basic pages up without having to bug the html people ;)
<div id="copyright" metal:define-macro="copyright"> This page ©2002 Foobly Enterprises LLC, all rights reserved. </div>
Now you reuse it in other pages with:
<div metal:use-macro="here/index_html/macros/copyright"></div>
No slots or other complications needed. Any TAL in the macro is executed as though it were part of the page that's using it, so you don't need to worry about passing parameters, or losing context, or any of the difficulties introduced by calling one template from another. An addition advantage over <span tal:replace="structure here/zpt_snippet"> is that a single page can define any number of independent macros.
I have no use for this, because I can already do it by calling via tal:replace - and I prefer tal:replace, because it allows me to keep each snippet in a separate file, inside a common folder - which to my mind is far better(tm) than having to declare all those snippets in a single file. And, what's more, tal naming is easier to explain to non-coders - adding the /macros/macro_name, as simple as it is, is a common source of initial confusion/error on behalf of the html people. They understand "refer to that page in that folder", they don't understand "refer to the macro name in the "macros" namespace of that page in that folder". YMMV, KevinL
On Sunday, June 2, 2002, at 08:36 AM, Page Page wrote:
I like page templates because they permit uncomplicated cooperation with designers who don't know DTML and/or use drag-and-drop composers. Newbie I am, however, I see a few problems here, and I hope they stem from my ignorance.
1.) Can page templates be "modularized"? DTML is great for assembling pages from re-usable blocks, i.e. dtml_standard_header, dtml_standard_footer. I have not found an equivalent facility for page templates. Is there any?
METAL, one of the three components of ZPT <dtml-var standard_html_header> <dtml-var "banner_ad('car_ad')"> My content </dtml-var standard_html_footer> becomes <html metal:use-macro="here/standard_template.pt/macros/page> <body> <div tal:replace="python: here.banner_ad('car_ad')">Banner Ad</div> <div metal:fill-slot="body"> My content </div> </body> </html> And if you need to mix DTML and ZPT, your standard_template.pt can even use your existing standard_html_header and standard_html_footer (but this is probably defeating the purpose of using ZPT anyway...)
2.) Symbols How am I supposed to work with symbolic information like table width? Of course, I'm free to create python-functions which pull the raw figures from a config-file or db, but having a separate function for each of the dozens of symbols I would need will give me carpal tunnel syndrome.
Exactly the same way you already do in DTML if you want. <table width="<dtml-var global_tab_width>">...</table> becomes <table tal:attributes="width here/global_tab_width">...</table>
3.) Dynamic pages This is a more generic newbie question, since it is not confined to the realms of page templates. Let's say my site sports a uniform layout for hundreds of used-car ads. Each ad gets its own page which content is pulled from a data-base on the fly. This content is wrapped into identical hooks for banner ads, a header, footer and navigation bar. Without Zope one sets up a table of content with a link to each ad; each link calls a cgi-script with some id for the data-base in the QUERY_STRING. This requires the script to assemble the page, send the cgi-ahoy (content-type: text/blabla) and the <html> for the page. Is there a Zope-ish way to do this? I have not even found a way to access a page template from a script for reading. The data for Zope-objects seems to be pickled in files.db.
This could be done with four methods: 2 x ZSQL methods, one generating a list of ad ids for your table of contents, another one returning the contents for a specific ad. 2 x ZPT pages, one rendering the list of ads using a tal:repeat, and the other one rendering a single ad. If these two share a common look and feel, you would also have a third ZPT document (standard_template.pt, or whatever you want to call it). You can also avoid using an external database entirely if you like, storing your ad contents in ZODB instead (this is the most Zopeish method I guess). -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/
Stuart Bishop wrote:
<dtml-var standard_html_header> <dtml-var "banner_ad('car_ad')"> My content </dtml-var standard_html_footer>
becomes
<html metal:use-macro="here/standard_template.pt/macros/page> <body> <div tal:replace="python: here.banner_ad('car_ad')">Banner Ad</div> <div metal:fill-slot="body"> My content </div> </body> </html>
I think those 2 <div> tags in the ZPT example need to be switched, so the banner add div is inside the fill-slot div, since that's part of the content you want inserted into the standard template. Barry
Stuart Bishop wrote:
<html metal:use-macro="here/standard_template.pt/macros/page> <body> <div tal:replace="python: here.banner_ad('car_ad')">Banner Ad</div> <div metal:fill-slot="body"> My content </div> </body> </html>
Al little bit neater and more correct: <html metal:use-macro="here/standard_template.pt/macros/page> <body metal:fill-slot="body"> <tal:r replace="python: here.banner_ad('car_ad')"/> My content </body> </html>
2.) Symbols How am I supposed to work with symbolic information like table width? Of course, I'm free to create python-functions which pull the raw figures from a config-file or db, but having a separate function for each of the dozens of symbols I would need will give me carpal tunnel syndrome.
I know what you mean ;-) There's two approaches depending on how complex things are. If they're quite simple, you can just use inline paths and python: <table tal:attributes="border here/border_width"> <tr> <td width="10%"> </td> <td tal:attributes="width python:str(here.page_width-10)+'%'"> </td> </tr> </table> if they're complex, then you can have a python script which returns a dictionary: dict={} # information from context total_width = float(context.total_width) current = float(context.current_value) target = float(context.target_value) # width calculation red = (current/target)*total_width Netscape doesn't like images with a width of 0 if red==0: red=1 elif red==total_width: red-=1 # store retults dict['red'] = red dict['white'] = total_width - red return dict ...and use that in the ZPT: <td tal:define="widths here/calculateWidths"><img src="red.gif" height="10" tal:attributes="width widths/red"><img src="white.gif" height="10" tal:attributes="width widths/white"></td> cheers, Chris
participants (6)
-
Barry Pederson -
Chris Withers -
Evan Simpson -
KevinL -
Page Page -
Stuart Bishop