Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] wrote: > (snip) > If one is really interested in a separation of content and > presentation (which I feel is good), then the "standard_html_*" > were wrong in the first place. It forces the > content author to prepare for presentation. Here's a historical note on this decision. At the time that standard_html_* were introducted, DTML was used soley for creating templates to display content in Python objects. The expansion for DTML is Document *Template* Markup Language. The mistake was not introducing components, but introducing the use of DTML as content. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org 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. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] HiperDOM & xmlc
There are a few things I'm trying to understand about the xmlc-like Templates proposal. First : "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." http://lists.zope.org/pipermail/zope-dev/2000-September/006893.html 'Yep. Essentially the programmers "steal" the presentation/view layer from the designers and convert it to "code".' http://lists.zope.org/pipermail/zope-dev/2000-September/006958.html OK, point taken, but it's not quite that simple. In the end, isn't that why artist do design, and coders code? One of the primary purposes in a complete Content Management System is to distill the presentation standard in a way that can be "layered" over any content. This principle doesn't stop at a clearly delineated "visual" line. Leaving the page layout "as is", which is what it sounds like you are suggesting, is even worse than doing the job right at the "cast into code" stage. If you leave the ugly HTML ugly, it will still be ugly next time it gets updated, but it will be much less useful in the meantime. Worse, it's likely to get uglier over time. Have you ever seen a baby rhinocerous? To me the real solution is to clean up the layout, converting hard coded "virtual" lists into real lists, etc., while painstakingly preserving the visual design. That clean, codified version can then be leveraged to the utmost during it's production life, and still be fed back to the designer at design update time. This can be easily done today in the form of a static HTML file, simply by calling the Zope URL of the base template, and hitting "save as". With the proposed xmlc-ish Template, the "snapshot" step should not be needed, which is great! Granted, if the person who distills the design into clean, reusable HTML / DTML / XML hasn't done the job well, incorporating the changes of the updated version may well be a nightmare. On the other hand, if this crucial step is done well, adapting the base template to match the "new vision" should in fact be much easier the second time. I think a large part of the confusion comes from where we each draw the conceptual line regarding what is "visual" and what is best handled as "code". An anchor tag is, after all, just a pointer to some related stuff, not the actual physical location of anything. If making it easy for visual folks to avoid this basic fact is the driver here, there's a much larger problem looming in the immediate XML future . . . Also, the idea of presenting a place holder sounds a lot like : "As for cases where a dataset is displayed, such as by a ZSQL query, perhaps a single "dummy" row, or cell, could stand in for design purposes." http://www.zope.org/Resources/Mozilla/ZWiki/IDEs Is that what you mean? Is the "dummy" stuff intended to resemble the final content, or just to mark an insertion point? Might it be possible to make place holders in the form of anchors (links) to DTML Methods, or other appropriate forms of native Zope elements, so that DreamWeaver, et. al. can pull down a "real" item, rather than having a hard coded "stuff goes here" label? That sounds advantageous to me, in terms of validating a visual design. Groping toward grokking, Jerry S. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
I wanted to step back a few jumps in this thread and point out a few things... [EMAIL PROTECTED] 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 - 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
On Mon, Sep 18, 2000 at 03:12:14PM -0400, Shane Hathaway wrote: > [EMAIL PROTECTED] 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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] 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? Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
On Mon, Sep 18, 2000 at 08:34:51AM -0400, Shane Hathaway wrote: > [EMAIL PROTECTED] 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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] 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 and can be covered w/out sacrificing the really important parts of the proposal. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
From: Phillip J. Eby <[EMAIL PROTECTED]> [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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] wrote: > 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.) Great minds think alike. This is exactly what Jim came up with when we were presenting this idea. In fact, I like "asset" better than "component". IMHO the "asset" tag should always be generated by the server, not by a designer, so that it can contain the full physical path to the target object. > 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. Right. When a designer saves the page back to the server, it might contain pieces from 10 different places. My initial reaction is to say that the only assets the server should accept are the assets located within the target object. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
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... :) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
On Sun, Sep 17, 2000 at 03:51:35PM -0400, Shane Hathaway wrote: > [EMAIL PROTECTED] 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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] wrote: > On Sun, Sep 17, 2000 at 12:42:00PM -0400, Paul Everitt wrote: > > [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
On Sun, Sep 17, 2000 at 12:42:00PM -0400, Paul Everitt wrote: > [EMAIL PROTECTED] 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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] HiperDOM & xmlc
Hi Zope Gurus,
After looking over all the HiperDOM / xmlc stuff I think I'm starting to
"get it". I'll just summarize the things that ring especially true for me,
with some comments
Re. letting HTML "Page" Designers use familiar tools:
"Note that XMLC depends on legal HTML/XML markup that will not interfere
with other uses of the tags. HTML browsers are required to ignore tags and
attributes that they do not understand or use."
http://staff.plugged.net.au/dwood/xmlc/dynamic.html#sample_html
So, xmlc seems to be an alternative solution to the original motivation
behind embedding DTML within HTML Comment / Server Side Include style tags.
The convention exists, so that's a way Zope can fit in to Zope-unaware HTML
environments.
"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."
http://lists.zope.org/pipermail/zope-dev/2000-September/006899.html
However, it's hard to imagine that Web "Designers" can survive the XML wave
without becoming comfortable with inclusions. Doesn't the current version of
Dreamweaver have "folding" capability to "collapse" inclusions, such as
Javascript, and even entire tables, so only a pair of tags is displayed on
the screen? No doubt this feature will quickly become a "must have" item, as
fans of folding editors can attest. The verbosity of XML demands some
solution, and the usability of "folding" is well proven. At that point the
real question is, "If xmlc and DTML can both be easily included, collapsed,
etc., what sort of power and flexibility might be lost with an xmlc-ish
convention?"
Re. changing Bad Habits
"The current "header/footer" fragments are not optimal wrt. modularization,
as tightly coupled stuff ("footer" must close everything that "header"
opened) is separated into different objects."
http://lists.zope.org/pipermail/zope-dev/2000-September/006907.html
Certainly breaking well-formedness by placing HTML, HEAD, BODY, etc. in
standard_html_header, and closing HTML, HEAD, BODY, in standard_html_footer
was a dead end. But it's not at all difficult to package up as inclusions
all the other pieces-parts, while keeping HEAD, BODY, etc. within a
monolithic "wrapper". No doubt a multitude of other common DTML sins can
likewise be mended with diligent well-formedness.
"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)."
http://lists.zope.org/pipermail/zope-dev/2000-September/006899.html
The perceived "problem" with this approach is that the Designer sees
"nothing" where these items will be inserted. Actually, in edit mode they
can see a dtml-var tag. Yes, this can be confusing for Designers, but use of
inclusions is not really new, nor isolated to Zope. Anticpating "the
inclusion thing" will remain a persistent problem is based on the assumption
that Designers won't "learn to love" inclusions, which seems unlikely.
Re. kludging Zope to do "what they want"
Ideally, Zope's native ftp server can deliver DTML inclusions, which
DreamWeaver, et. al. can "cache" for display purposes. Can Zope's native ftp
server be taught to recognize such requests, and respond with a reasonable
(rendered) facsimile, even if some resources are not currently available?
That should keep visually oriented folks happy, since they'll be able to see
a mock-up, at least. If that's possible, the little gotcha of Dreamweaver
wanting to write back after updating might be handled politely too?
Meeting this need one way or another is the whole point of the "round trip",
edit vs. rendered discussion. So much for speculation about how a
hypothetical SuperZope might learn to recognize requests from an editing
tool, as opposed to some other ftp client. I know, ftp is not a smart
protocol . . .
Re. anti-inclusions, HTML "dummies"
"It is much better to have a module that contains both the page prolog and
epilog and a placeholder for the actual content, maybe filled in with sample
text that later is replaced by the content, i.e. a page template. It is good
that you are forced to use well formed XML in your modules."
http://lists.zope.org/pipermail/zope-dev/2000-September/006907.html
How is the "place-holder HTML that will never be rendered" solution any more
appropriate? Perhaps simply because it's possible, as opposed to the
mythical ftp beast above? It seems less so to me, at first glance. If we're
seriously concerned over Designer reactions to inclusions, what will they
say when we tell, them, "Just put anything there, for now, the system will
handle it?" If they can get used to "subtractions", what's the real problem
with "inclusions"? Aren't collapsed tags Good Enough as placeholders? It's a
"visual" thing?
Of course, I don't have a clear notion of how the xmlc model will change the
way methods are invoked, and the innate capacities of Zope to deliver
Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
Shane Hathaway writes:
> [EMAIL PROTECTED] 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 - 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!
I did not (yet) look at HiperDOM and xmlc. Nor am I familiar
with dreamweaver and friends.
Thus, maybe, I should not speak up.
If one is really interested in a separation of content and
presentation (which I feel is good), then the "standard_html_*"
were wrong in the first place. It forces the
content author to prepare for presentation.
The "page_template" proposal is much better in this respect,
as it is external to the content.
Of cause, there should be a way to select between different
page templates and not be bound to a fixed template (already
mentioned by a previous responder).
The other question deals with template modularity.
If a single modification should influence several templates,
then this is best addressed by building the templates out of
modules. The modification of a module then affects all
templates that use it.
Modularization would be possible if e.g. XSLT is
used for presentation. I do not know, whether Dreamweaver
has a modularization concept. I hope so.
The current "header/footer" fragments are not optimal wrt.
modularization, as tightly coupled stuff ("footer" must close
everything that "header" opened) is separated into
different objects. It is much better to have a module
that contains both the page prolog and epilog
and a placeholder for the actual content, maybe filled in with
sample text that later is replaced by the content, i.e.
a page template.
It is good that you are forced to use well formed XML
in your modules.
Dieter
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] HiperDOM & xmlc
On Fri, Sep 15, 2000 at 03:17:00PM -0400, Shane Hathaway wrote:
> [EMAIL PROTECTED] 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 - 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:
This will be overridden by the wrapper template
This will not appear in the document.
This will appear in the document.
HiperDOMDocument at /site_template:
Document title goes here via
aquisition
http://yoursite.com/site_css"
type="text/css"/>
Here goes the site navbar, which can be replaced by a
subsite-specific navbar thanks to aquisition
Here goes the actual body of the template, acquired from the
calling (wrapped) template via the hdom:id attribute
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:
Document title goes here via
aquisition
http://yoursite.com/site_css"
type="text/css"/>
Here goes the site navbar, which can be replaced by a
subsite-specific navbar thanks to aquisition
This will appear in the document.
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:[EMAIL PROTECTED]
pgp key: http://zope.gf.com.br/lalo/pessoal/pgp
Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] HiperDOM & xmlc
[EMAIL PROTECTED] 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 - 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
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 - 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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] HiperDOM & xmlc
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 [EMAIL PROTECTED] 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 +, 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. > > > > 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? > > []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:[EMAIL PROTECTED] > pgp key: http://zope.gf.com.br/lalo/pessoal/pgp > > Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] HiperDOM & xmlc
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 +, 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. > > 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? []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:[EMAIL PROTECTED] pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
