Re: [midgard-dev] ZPT, a next-generation template technology
Hamish, I first heard about this effort at OSDEM in February and it sounded promising then. If the design and implementation are easy to integrate I'd love to include it in Midgard 2.0. If it turns out to be a lot of effort, of course, we'll have to look at it closely and weigh the benefits, but the idea sounds solid. I don't have a lot of time to look at your proposals closely right now (although some other Midgard developers may), but I'll make sure we consider them before building our own templates for Midgard 2.0. Regards, Ami. On Sat, 10 March 2001, Hamish Lawson wrote:
The Zope Presentation Templates project is underway to develop a next-generation template technology for Zope* that is XHTML-compliant and which makes it easier for designers to work with. However it is hoped to design it in such a way that as much as possible is not specific to Zope, in the belief that the technology is more widely useful and could be adopted by other languages and tools. I'm extending an invitation (in a personal capacity rather than as an official spokesman for the project) to developers from other communities to consider contributing to the design of ZPT to help keep it language-independent, and to consider implementing the approach in their programming language of choice.
.. . . . . . . . . Aurora R&D www.aurora-linux.com Midgard Developer www.midgard-project.org
Ami Ganguli wrote:
I first heard about this effort at OSDEM in February and it sounded promising then. If the design and implementation are easy to integrate I'd love to include it in Midgard 2.0. If it turns out to be a lot of effort, of course, we'll have to look at it closely and weigh the benefits, but the idea sounds solid.
There's a number of things in the TALES bit which explicitly refer to Zope entities. We'd need to rework this to more generalized entities. Regarding the metal macros: inserting the entire macro but in fact only allowing the editing of slots could lead to confusion. In the example on http://www.zope.org/Wikis/DevSite/Projects/ZPT/METAL, I assume that if I edit the text 'Links' in doc2, save it, then reedit, that particular change would be gone. Which would be counter to what I expect. Also, if macros call macros themselves, would this be unfolded in its entirety every time I edit? Emile
From: "Emiliano" <emile@iris-advies.com>
There's a number of things in the TALES bit which explicitly refer to Zope entities. We'd need to rework this to more generalized entities.
Most of the stuff in the TALES document describes our particular implementation of TALES. Path expressions, in particular, are quite tailored to the Zope environment. These details could certainly be adopted by another implementation, but the only thing that is really intrinsic to TALES is the idea of expression types, and the syntax "typename:expression text".
Regarding the metal macros: inserting the entire macro but in fact only allowing the editing of slots could lead to confusion. In the example on http://www.zope.org/Wikis/DevSite/Projects/ZPT/METAL, I assume that if I edit the text 'Links' in doc2, save it, then reedit, that particular change would be gone. Which would be counter to what I expect.
We worked for a while with the idea of propagating changes to inserted macros back to the macro definition, but it raised too many questions that we weren't prepared to answer. I hope that we can find ways to mark macro bodies read-only that can be made compatible with the most popular HTML editors.
Also, if macros call macros themselves, would this be unfolded in its entirety every time I edit?
Yes. The idea of macros is to make the editor's copy match the rendered page as closely as is reasonable. This way, the person responsible for layout and visual design isn't confronted with a broken page, or one missing significant structural elements. Cheers, Evan @ digicool
Evan Simpson wrote:
Most of the stuff in the TALES document describes our particular implementation of TALES. Path expressions, in particular, are quite tailored to the Zope environment. These details could certainly be adopted by another implementation, but the only thing that is really intrinsic to TALES is the idea of expression types, and the syntax "typename:expression text".
I think it would help a lot if the descriptions do not focus on one particular implementation in this phase of the design.
We worked for a while with the idea of propagating changes to inserted macros back to the macro definition, but it raised too many questions that we weren't prepared to answer.
I don't really think that's a good idea. The macro user may not have proper access to change the macro. Assuming that these components would be covered by some sort of access control, that is.
I hope that we can find ways to mark macro bodies read-only that can be made compatible with the most popular HTML editors.
Are there editors out there that support these kinds of editing modes? It could be interestign to see how they approach this. Personally I don't know of any.
Also, if macros call macros themselves, would this be unfolded in its entirety every time I edit?
Yes. The idea of macros is to make the editor's copy match the rendered page as closely as is reasonable. This way, the person responsible for layout and visual design isn't confronted with a broken page, or one missing significant structural elements.
I understand, but it would be essential that it is possible to mark parts of such a page as read-only. Emile
hi, I just created an external method that... def test(self): import sys return sys.modules ...and then a DTML method that... <dtml-in "test().keys()"> <b><dtml-var sequence-item></b><br> <dtml-let x=sequence-item> <dtml-var expr="dir(x)"> </dtml-let> <br><br> </dtml-in> ...because I was try to get zope to describe itself. What I want to do is use the odbc stuff from within an external method. Is this possible? And why doesn't dir(x) in the DTML above work? thanks tom
participants (4)
-
Ami Ganguli -
Emiliano -
Evan Simpson -
tom smith