Zope Devers, THis is going to seem strange coming from someone who hasn't been on the list in a long time, but I was at the Linux Expo in San Jose, and sat in on a Web app talk. Lutris was in charge of the panel, and they talked about xmlc. I went to their booth and asked about it. I think it could be the best way to get hard-core python people to jump on zope's band-wagon, and stop the dtml frowning. If you who are in the know about zope have time, please read a quick bit on what it is. http://xmlc.enhydra.org Especially the tutorial: http://staff.plugged.net.au/dwood/xmlc/index.html Is there any obvious reason why Zope wouldn't benefit tremendously from this design and programming separation and pure python boost? All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
We (I and Hiperlogica, a company I consult with) have been developing a template renderer with similar intent to xmlc (be based on XML/DOM, allow the template to be previewed and edited using tools not aware of the format, such as xHTML editors, and enforce presentation/logic separation). As the project is somewhat on hold while we have more pressing issues, I decided to share the current (rather kludgy) prototype with the community. It is at http://www.zope.org/Members/lalo/HiperDOM/ On Mon, Sep 11, 2000 at 02:06:08PM +0000, Jason Spisak wrote:
Zope Devers,
THis is going to seem strange coming from someone who hasn't been on the list in a long time, but I was at the Linux Expo in San Jose, and sat in on a Web app talk. Lutris was in charge of the panel, and they talked about xmlc. I went to their booth and asked about it. I think it could be the best way to get hard-core python people to jump on zope's band-wagon, and stop the dtml frowning.
If you who are in the know about zope have time, please read a quick bit on what it is.
Especially the tutorial:
http://staff.plugged.net.au/dwood/xmlc/index.html
Is there any obvious reason why Zope wouldn't benefit tremendously from this design and programming separation and pure python boost?
[]s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
I'm surprised that no one responded to this. (Or maybe people did and our continual email server problems have lost it.) I'd like to congratulate Hiperlogica, because they have (ding ding ding) the _right answer_! :^) Seriously, we at Digital Creations have been quietly formulating a proposal on this since Amos put up the template proposal in dev.zope.org. I floated some trial balloons at EuroZope and it's clear there's some consensus. Our "XHTML Templates Proposal" is at: http://dev.zope.org/Wikis/DevSite/Proposals/XHTMLTemplatesProposal Since Wiki is having a tough time on the list here lately, I'll post the text in a message in just a second. To summarize, we at DC at least think that Hiperglocia is on to the right thing and we'd like to indicate support for that direction. --Paul lalo@hackandroll.org wrote:
We (I and Hiperlogica, a company I consult with) have been developing a template renderer with similar intent to xmlc (be based on XML/DOM, allow the template to be previewed and edited using tools not aware of the format, such as xHTML editors, and enforce presentation/logic separation).
As the project is somewhat on hold while we have more pressing issues, I decided to share the current (rather kludgy) prototype with the community. It is at http://www.zope.org/Members/lalo/HiperDOM/
On Mon, Sep 11, 2000 at 02:06:08PM +0000, Jason Spisak wrote:
Zope Devers,
THis is going to seem strange coming from someone who hasn't been on the list in a long time, but I was at the Linux Expo in San Jose, and sat in on a Web app talk. Lutris was in charge of the panel, and they talked about xmlc. I went to their booth and asked about it. I think it could be the best way to get hard-core python people to jump on zope's band-wagon, and stop the dtml frowning.
If you who are in the know about zope have time, please read a quick bit on what it is.
Especially the tutorial:
http://staff.plugged.net.au/dwood/xmlc/index.html
Is there any obvious reason why Zope wouldn't benefit tremendously from this design and programming separation and pure python boost?
[]s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are.
http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp
Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Fri, Sep 15, 2000 at 08:21:21AM -0400, Paul Everitt wrote:
I'm surprised that no one responded to this. (Or maybe people did and our continual email server problems have lost it.)
Me too.
I'd like to congratulate Hiperlogica, because they have (ding ding ding) the _right answer_! :^)
Thank you :-) We feel good about this answer too.
Seriously, we at Digital Creations have been quietly formulating a proposal on this since Amos put up the template proposal in dev.zope.org. I floated some trial balloons at EuroZope and it's clear there's some consensus.
Glad to know that.
Our "XHTML Templates Proposal" is at:
http://dev.zope.org/Wikis/DevSite/Proposals/XHTMLTemplatesProposal
It is not linked on the Proposals FrontPage... -- Anyway, at least for HiperDOM I feel comfortable with the word "template" because that's what it is about. The two primary motivations for the design are: * You can create the layout with any XML-compliant editor; if the template is xHTML, you can use a XHTML-compliant WYSIWYG tool. Or, thanks to the modern XML technology, you can use a WYSIWYG HTML tool and pass it trough a SGML->XML filter to get xHTML. Using specialized webdesigners with Zope project has been one of the biggest pains in Zope development; we have to take the sometimes ugly code generated by the tools they use, usually clean it up, then insert the DTML tags in it. Making changes to the design is a nightmare. * The template looks like the rendered page; if you don't want to fire up Zope, or if the application logic is not yet finished, you can preview the layout by simply loading the template in a browser. These goals are similar, but not identical to the ones in the proposal. Still, some parts of the proposal felt like extracted rigth out of my mind :-) I don't feel good about calling the layers "document" and "view" or "presentation" and "data" because the "view" is not strictly presentation code; invariant (static) parts shared by all pages rendered with that template can be in the template. As much as we all like to talk about "Web Applications", this is not exactly like "normal" application design, where you can draw a clear line between presentation and data (or model/view). -- The only thing I _don't_ feel good about this kind of template is that, in practice, we will probably lose the benefits of things like <dtml-var standard_html_header> - meaning, when you want to change the header of your site, you'll have to edit all your templates. Of course a site where this is a problem still _can_ use "includes" like standard_html_header, but I believe most won't. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
lalo@hackandroll.org wrote:
The only thing I _don't_ feel good about this kind of template is that, in practice, we will probably lose the benefits of things like <dtml-var standard_html_header> - meaning, when you want to change the header of your site, you'll have to edit all your templates.
I agree this is a problem, and speaking from experience, changing all templates is not an acceptable compromise. For www.zope.org that would mean including the standard template in nearly every page, everywhere, because the pages on www.zope.org are nearly all "templates" themselves. We would lose one of the primary benefits of Zope. Another unacceptable compromise is including a variant of standard_html_header and _footer on every page (as is done now). One reason is because it is not possible to write standard_html_header/_footer using well-formed XML. The header begins the "html" tag, while the footer ends it. In fact, most sites these days put the beginning of a table in _header and the end of the table in _footer. Objects containing non-well-formed XML aren't compatible with a DOM-based solution. This has been one of the points of discussion here at DC. The only reasonable solution we've come up with is automatically wrapping the results of the rendering in an acquired object with a fixed name such as standard_page_template. The other solution that I have tried to wrestle with is introducing some kind of multiple view system with automatic selection of the default view. But in reality, the standard_page_template solution would make the multiple view system possible as well. So what does everyone think? Is standard_page_template the right thing to do? Is there a better way? Help! Shane
On Fri, Sep 15, 2000 at 03:17:00PM -0400, Shane Hathaway wrote:
lalo@hackandroll.org wrote:
The only thing I _don't_ feel good about this kind of template is that, in practice, we will probably lose the benefits of things like <dtml-var standard_html_header> - meaning, when you want to change the header of your site, you'll have to edit all your templates.
I agree this is a problem, and speaking from experience, changing all templates is not an acceptable compromise. For www.zope.org that would mean including the standard template in nearly every page, everywhere, because the pages on www.zope.org are nearly all "templates" themselves. We would lose one of the primary benefits of Zope.
But using external fragments ("includes") is not a natural idea for web designers. One of the main points of this fuss is to allow them to create the templates in something like Dreamweaver.
Another unacceptable compromise is including a variant of standard_html_header and _footer on every page (as is done now). One reason is because it is not possible to write standard_html_header/_footer using well-formed XML. The header begins the "html" tag, while the footer ends it. In fact, most sites these days put the beginning of a table in _header and the end of the table in _footer. Objects containing non-well-formed XML aren't compatible with a DOM-based solution.
I hadn't thought of this. Of course you can already use "includes" which are valid XML, such as a single row or cell of a table (for example, the navbar of a complex site).
This has been one of the points of discussion here at DC. The only reasonable solution we've come up with is automatically wrapping the results of the rendering in an acquired object with a fixed name such as standard_page_template.
I don't like fixed names :-) what if I don't want to wrap a particular template? One sollution that could possibly work: HiperDOMDocument at /foo/bar/somepage: <html hdom:wrapper="site_template"><head> <title>This will be overridden by the wrapper template</title> </head><body> This will not appear in the document. <div hdom:id="someVariableName"> This will appear in the document. </div> </body> </html> HiperDOMDocument at /site_template: <html><head> <title hdom:text="title">Document title goes here via aquisition</title> <link rel=stylesheet href="http://yoursite.com/site_css" type="text/css"/> </head> <body bgcolor="white"> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td bgcolor="#6699cc" hdom:text="navbar"> Here goes the site navbar, which can be replaced by a subsite-specific navbar thanks to aquisition</td> <td hdom:text="someVariableName"> Here goes the actual body of the template, acquired from the calling (wrapped) template via the hdom:id attribute</td> </tr> </table> </body> </html> To add even more sugar, there could be a button in the management interface of the "somepage" document to automagically merge it with the (current) wrapper so that it reads: <html hdom:wrapper="site_template"><head> <title hdom:text="title">Document title goes here via aquisition</title> <link rel=stylesheet href="http://yoursite.com/site_css" type="text/css"/> </head> <body bgcolor="white"> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td bgcolor="#6699cc" hdom:text="navbar"> Here goes the site navbar, which can be replaced by a subsite-specific navbar thanks to aquisition</td> <td hdom:text="someVariableName" hdom:id="someVariableName"> This will appear in the document. </td> </tr> </table> </body> </html> This would make the Dreamweaver freaks happy, I think. BTW, please don't call the solution "xHTML Template"; it's not xHTML, it's generic XML - it can easily be used for RSS or WML or MathML or NewsML for example. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
lalo@hackandroll.org wrote:
BTW, please don't call the solution "xHTML Template"; it's not xHTML, it's generic XML - it can easily be used for RSS or WML or MathML or NewsML for example.
While it *can* be used that way (just as DTML can be used to send mail messages), that's not the real intent of this proposal nor is that the real audience. Our proposal it focused on letting HTML-oriented people with HTML-oriented tools create compliant stuff for the presentation job. At the same time, the markup must be compliant XML or it won't work. The W3C has a term for the intersection of these two spaces: XHTML. :^) Finally, I think the notion of XHTML stylesheets (or templates) could really catch flight beyond Zope, which would be good for everybody. --Paul
On Sun, Sep 17, 2000 at 12:42:00PM -0400, Paul Everitt wrote:
lalo@hackandroll.org wrote:
BTW, please don't call the solution "xHTML Template"; it's not xHTML, it's generic XML - it can easily be used for RSS or WML or MathML or NewsML for example.
While it *can* be used that way (just as DTML can be used to send mail messages), that's not the real intent of this proposal nor is that the real audience. Our proposal it focused on letting HTML-oriented people with HTML-oriented tools create compliant stuff for the presentation job.
Why? WML-oriented people with WML-oriented tools would benefit from it just as much, for example. (Are there WML-oriented tools already?) []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
lalo@hackandroll.org wrote:
On Sun, Sep 17, 2000 at 12:42:00PM -0400, Paul Everitt wrote:
lalo@hackandroll.org wrote:
BTW, please don't call the solution "xHTML Template"; it's not xHTML, it's generic XML - it can easily be used for RSS or WML or MathML or NewsML for example.
While it *can* be used that way (just as DTML can be used to send mail messages), that's not the real intent of this proposal nor is that the real audience. Our proposal it focused on letting HTML-oriented people with HTML-oriented tools create compliant stuff for the presentation job.
Why? WML-oriented people with WML-oriented tools would benefit from it just as much, for example. (Are there WML-oriented tools already?)
What Paul is saying is that we need to make it work for XHTML first. It makes it easier to talk about with those less familiar with XML (especially XML namespaces.) Then with a very small amount of work we can expand it to all XML schemas. (BTW I seem to recall that WML just got replaced by XHTML. :-/ ) Shane
On Sun, Sep 17, 2000 at 03:51:35PM -0400, Shane Hathaway wrote:
lalo@hackandroll.org wrote:
Why? WML-oriented people with WML-oriented tools would benefit from it just as much, for example. (Are there WML-oriented tools already?)
What Paul is saying is that we need to make it work for XHTML first. It makes it easier to talk about with those less familiar with XML (especially XML namespaces.) Then with a very small amount of work we can expand it to all XML schemas.
I can see how this makes sense as a strategy, but technically it just doesn't... we're not using any features specific to xHTML, and by all means we shouldn't. So, the way it is today it already works with any XML schema. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
lalo@hackandroll.org wrote:
On Fri, Sep 15, 2000 at 03:17:00PM -0400, Shane Hathaway wrote:
This has been one of the points of discussion here at DC. The only reasonable solution we've come up with is automatically wrapping the results of the rendering in an acquired object with a fixed name such as standard_page_template.
I don't like fixed names :-) what if I don't want to wrap a particular template?
I don't like fixed names either. They can lead to bad design. That's why we're still looking for a better solution.
One sollution that could possibly work: (snip)
We think alike. A few of us tried to present this very solution (with a different spelling) to several people here at DC. They found it quite confusing. I honestly don't know why. :-/ But assuming someone can properly document this without making heads hurt and without sounding alarms in the minds of OO folks, maybe the right solution is an optional attribute on the opening tag that specifies the wrapping template. If not specified, it would default to "standard_page_template". Of course, the name of the default wrapping template could always be overridden by the document class. Instances of 'NewsDocument', for example, might use "standard_news_template". Shane
On Sun, Sep 17, 2000 at 04:07:18PM -0400, Shane Hathaway wrote:
One sollution that could possibly work: (snip)
We think alike. A few of us tried to present this very solution (with a different spelling) to several people here at DC. They found it quite confusing. I honestly don't know why. :-/
Tell them that "It is confusing" without a reason doesn't help us come up with a better sollution :-)
But assuming someone can properly document this without making heads hurt and without sounding alarms in the minds of OO folks, maybe the right solution is an optional attribute on the opening tag that specifies the wrapping template. If not specified, it would default to "standard_page_template".
Nonono. If the attribute is not specified, the page is a standalone template and is not wrapped at all. This is important. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
lalo@hackandroll.org wrote:
But assuming someone can properly document this without making heads hurt and without sounding alarms in the minds of OO folks, maybe the right solution is an optional attribute on the opening tag that specifies the wrapping template. If not specified, it would default to "standard_page_template".
Nonono. If the attribute is not specified, the page is a standalone template and is not wrapped at all. This is important.
But, you see, this solution sounded an alarm for the OO folks here at DC. I wanted it just as you say. But when it was presented this way, everyone figured that the effect was that the model was specifying the view... and that's just wrong. I agree with them in one regard--models should not specify views. But as I see it (and as I think you do as well), we're not on the model layer at all. All of this is *only* on the view or "presentation" layer. So the standard_page_template default wrapping is an attempt at a compromise. How about this compromise instead: two new object types would be available, Document and XHTMLDocument. Document objects would have no default wrapper while XHTMLDocuments would. This would actually match the desires of a *lot* of people IMHO. Shane
On Mon, Sep 18, 2000 at 08:34:51AM -0400, Shane Hathaway wrote:
lalo@hackandroll.org wrote:
Nonono. If the attribute is not specified, the page is a standalone template and is not wrapped at all. This is important.
But, you see, this solution sounded an alarm for the OO folks here at DC. I wanted it just as you say. But when it was presented this way, everyone figured that the effect was that the model was specifying the view... and that's just wrong. I agree with them in one regard--models should not specify views. But as I see it (and as I think you do as well), we're not on the model layer at all. All of this is *only* on the view or "presentation" layer.
Obviously. Templates (Hiperdom or XHTMLWhatever) are the view. The model is the set of objects and methods that store and process the data. Both templates - the page template and the wrapper - are components of the presentation layer. The concept of a wrapper is just another cool feature to make people's lives easier; is basically about building a presentation from a prototype.
So the standard_page_template default wrapping is an attempt at a compromise.
It's wrong. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
On Mon, Sep 18, 2000 at 03:12:14PM -0400, Shane Hathaway wrote:
lalo@hackandroll.org wrote:
So the standard_page_template default wrapping is an attempt at a compromise.
It's wrong.
Please elaborate your position. :-)
Why is it wrong?
Because, as we said, the HiperDOM/xHTMLTemplate template is already a "view", already part of the presentation layer. The standard_page_template default wrapping is an attempt to conjure a new "meta-presentation" layer out of nothing. It solves a problem but creates more, because most people will _not_ want the wrappers at all. Wrappers re-create the infamous "source vs. rendered issue" and there's no easy way out of that; they may be an useful functionality, but they're an UI nightmare. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
At 04:07 PM 9/17/00 -0400, Shane Hathaway wrote:
We think alike. A few of us tried to present this very solution (with a different spelling) to several people here at DC. They found it quite confusing. I honestly don't know why. :-/
But assuming someone can properly document this without making heads hurt and without sounding alarms in the minds of OO folks, maybe the right solution is an optional attribute on the opening tag that specifies the wrapping template. If not specified, it would default to "standard_page_template".
Of course, the name of the default wrapping template could always be overridden by the document class. Instances of 'NewsDocument', for example, might use "standard_news_template".
Suppose that you could add to any element an hdom:asset="nameOrPath" attribute. When saving a template containing such elements, the content of the named document is compared against the tagged block in the template being saved, and against the previous version of the template. If the content has not been changed since the last version of the template, but the asset itself is different, the named portion is silently replaced with the new version of the asset. If the content *has* been changed, the author is given the option of updating the named object with the changed contents, undoing the change, attempting to merge changes, etc. If an asset is named in a template being saved, but no such object exists, it is automatically created as a peer of the template (and of course it can be moved higher in the tree for acquisition without breaking the reference). And last, but not least, if one is creating a new template, and the named element is empty, it is replaced with the referenced asset. (Actually, in practice you'd do almost all of this not by copying XML fragments but by using DOM objects that were symlink-ish.) That was a very terse way of describing the idea, but I think that it could preserve the Zope/programmerish notion of fragments while preserving the editability of documents. And it seems to me it would be an easy sell to any web designer who isn't afraid to manually add an attribute or two to their code, in exchange for not having to repeat themselves so often. Yes, you say, but what about the problem you're talking about, where the wrapper is not well-formed? Just take the same basic idea and turn it inside out, and have a hdom:wrapper="nameOrPath" attribute which could be added to one and only one element within the page. Anything which is *outside* (around?) this block is then treated in much the same way I described for an "asset". (Meanwhile, assets as previously described would be usable both inside and outside the central block.) The effective external behavior of these two attributes, would be to let a web designer load and save any page or template they wished in the site, freely making changes to the header, footer, or various embedded elements thereof, and then save that *one* page, and have those style changes propagated throughout the relevant areas of the site. This could potentially be a "killer feature" for web designers. The tricky bit is managing UI handling for what happens when they save their page. WebDAV and FTP are all very well and good, but unfortunately, they don't have any convenient way to pop up a dialog box and let you prompt the user to replace/update things. You'd have to have this do some sort of workflow notification, or a way for the designer to go in and review what things might need to be updated. Anyway, just thought I'd throw a few more ideas on the fire... :)
From: Phillip J. Eby <pje@telecommunity.com> [snip description]
The effective external behavior of these two attributes, would be to let a web designer load and save any page or template they wished in the site, freely making changes to the header, footer, or various embedded elements thereof, and then save that *one* page, and have those style changes propagated throughout the relevant areas of the site.
Exactly. You've just described the "components" aspect of this idea, which was left out of the Paul's original post. A component is just a tag marked with a special attribute that names it (and its path, if it has been saved). It can contain other components, and can have "slots" -- subtags whose contents are not part of the component. There is also the concept of "modes", which allows you to have different versions of a template for different system states (shopping cart empty vs. non-empty) that radically affect presentation.
This could potentially be a "killer feature" for web designers.
Yep :-) Cheers, Evan @ digicool & 4-am
evan@4-am.com wrote:
Exactly. You've just described the "components" aspect of this idea, which was left out of the Paul's original post. A component is just a tag marked with a special attribute that names it (and its path, if it has been saved). It can contain other components, and can have "slots" -- subtags whose contents are not part of the component. There is also the concept of "modes", which allows you to have different versions of a template for different system states (shopping cart empty vs. non-empty) that radically affect presentation.
I viewed components and modes as implementation details. The proposal just suggested that designers should have reuse across pages. I viewed (and still view) components as a good idea, but definately magic that might or might not fly. It might tip the cognitive scales too far for average site designers, especially if there are other areas of magic in the implementation of the proposal (like implicit templates). Let's just have the proposal say reuse is good and then figure it out later. Same for modes: let's just say the important areas in DTML will be covered, and find out later whether <dtml-if> and <dtml-in> can be covered w/out sacrificing the really important parts of the proposal. --Paul
I wanted to step back a few jumps in this thread and point out a few things... lalo@hackandroll.org wrote:
Our "XHTML Templates Proposal" is at:
http://dev.zope.org/Wikis/DevSite/Proposals/XHTMLTemplatesProposal
It is not linked on the Proposals FrontPage...
You're right, I'll get that done today. I just wanted to get some initial comments from you and others.
--
Anyway, at least for HiperDOM I feel comfortable with the word "template" because that's what it is about. The two primary motivations for the design are:
Ultimately I think that's what is going to work for everybody.
* You can create the layout with any XML-compliant editor; if the template is xHTML, you can use a XHTML-compliant WYSIWYG tool. Or, thanks to the modern XML technology, you can use a WYSIWYG HTML tool and pass it trough a SGML->XML filter to get xHTML.
Right, though our real goal was to make it work with existing, here-now HTML tools like Dreamweaver and GoLive.
Using specialized webdesigners with Zope project has been one of the biggest pains in Zope development; we have to take the sometimes ugly code generated by the tools they use, usually clean it up, then insert the DTML tags in it. Making changes to the design is a nightmare.
Yep. Essentially the programmers "steal" the presentation/view layer from the designers and convert it to "code".
* The template looks like the rendered page; if you don't want to fire up Zope, or if the application logic is not yet finished, you can preview the layout by simply loading the template in a browser.
I think this is going to be the breakthrough over all other approaches out there. Allowing sample data (your "dummy" attribute) is huge. The downsides I see to using template; o Word processors like Word have a different usage of template. o The W3C uses "stylesheet" to cover activity in the presentation/view tier.
These goals are similar, but not identical to the ones in the proposal. Still, some parts of the proposal felt like extracted rigth out of my mind :-)
Actually they are identical. If my wording wasn't clear I need to change it.
I don't feel good about calling the layers "document" and "view" or "presentation" and "data" because the "view" is not strictly presentation code; invariant (static) parts shared by all pages rendered with that template can be in the template. As much as we all like to talk about "Web Applications", this is not exactly like "normal" application design, where you can draw a clear line between presentation and data (or model/view).
Unfortunately we have to make it clear. That's just the way to world thinks, and Zope pays the price for being so different on so many things. We're trying hard to give people an organizational framework that is approachable. Just saying "it's objects" hasn't proven helpful. :^)
The only thing I _don't_ feel good about this kind of template is that, in practice, we will probably lose the benefits of things like <dtml-var standard_html_header> - meaning, when you want to change the header of your site, you'll have to edit all your templates.
Of course a site where this is a problem still _can_ use "includes" like standard_html_header, but I believe most won't.
One of the reasons it took us so long to get the proposal out is that I wanted to specify the complete architecture for both documents and templates. I thought it imperative to decide how a document is "bound" to a template and how a template looks at a document. The first revisions were for a "Document and Template Architecture" proposal. I was convinced to drop this and move it to a forthcoming "Document Architecture" proposal. The user manual material I wrote for documents and templates on vacation covered what I consider a response to your issue above. Basically, when a document is rendered, a series of rules are applied to decide which template to use. The document can specify its template (perhaps with a meta tag), a folder can decide, an acquired folder can decide, a ZClass can decide, etc. Perhaps we need to make progress on the document side... --Paul
On Tue, Sep 19, 2000 at 09:00:03AM -0400, Paul Everitt wrote:
* You can create the layout with any XML-compliant editor; if the template is xHTML, you can use a XHTML-compliant WYSIWYG tool. Or, thanks to the modern XML technology, you can use a WYSIWYG HTML tool and pass it trough a SGML->XML filter to get xHTML.
Right, though our real goal was to make it work with existing, here-now HTML tools like Dreamweaver and GoLive.
If the library can handle SGML, fine. I don't know what is the status of the 4Thought/DC stuff, I was thinking of using xml.dom.utils in the meanwhile - and it supports HTML and SGML, but it has to be reasonably well-formed (yesterday it barfed on a few files I had locally which display normally on a browser).
* The template looks like the rendered page; if you don't want to fire up Zope, or if the application logic is not yet finished, you can preview the layout by simply loading the template in a browser.
I think this is going to be the breakthrough over all other approaches out there. Allowing sample data (your "dummy" attribute) is huge.
That idea was Luciano's (*) and I agree, this is what made me jump in the project. (*) Luciano Ramalho is the kind-of-infomally-CEO of Hiperlogica
The downsides I see to using template;
o Word processors like Word have a different usage of template.
Not very different. You start from a template and edit it with the data you want. HDom does just that, but automatically.
o The W3C uses "stylesheet" to cover activity in the presentation/view tier.
But these are a different kind of activity. In most practical applications there will probably be a template _and_ a stylesheet.
These goals are similar, but not identical to the ones in the proposal. Still, some parts of the proposal felt like extracted rigth out of my mind :-)
Actually they are identical. If my wording wasn't clear I need to change it.
On the first read, I thought the order of the priorities was not the same. Now I'm not so sure. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
We released HiperDom 0.1 Saturday (this message is dated Monday because it's when the objects got cataloged). This version is Python-based, fully functional to the last letter of the spec (except for hdom:method where we cleaned up the interface a bit), fully HelpSys'ed, heck, it even has an icon. Oh, it has an undocumented feature too. Actually lots of 'em; I have to write about manage_getTemplate somewhere for the next version... but what I'm talking about right now is the hdom:id directive used for creating "assets" like we discussed previously in the "HiperDOM and xmlc" thread. When you expand a section marked with hdom:text, before discarding the contents, the engine hunts for elements marked with hdom:id in it. Those found are added to the namespace. ... <p hdom:text="greeting">This paragraph will be replaced by a greeting to <span hdom:id="person">Lalo</span> and <span hdom:id="company">Hiperlógica</span>.</p> ... The method "greeting" will be executed with a namespace as **kw (I don't know how flexible is this, but it's how DTML does it). In this namespace there will be at least {'person': '<span>Lalo</span>', 'company': '<span>Hiperlógica</span>'}. This feature isn't documented on purpose, since this subject is far from settled and it is very possible that this isn't the best sollution. But it's _a_ sollution and it's there to be tested - "running code" :-) We'll be away from this code for about two weeks, as we have an urgent job to deliver to a big customer whose identity is so ironic that I'll have to tell you folks as soon as I'm sure I'm allowed to. Anyway, I'd like everyone interested to try it out in this meantime, send us your feedback, and discuss it here and/or on the HiperDomWiki. I'll have an eye (and a few fingers) on this discussion. Thank you for your time, have a nice day. :-) []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
participants (6)
-
Evan Simpson -
Jason Spisak -
Lalo Martins -
Paul Everitt -
Phillip J. Eby -
Shane Hathaway