Benji York wrote:
Martijn Faassen wrote:
Right, that was my motivation too - I googled around for
javascript-based templating languages but realized there wasn't
really anything. Of course XSLT can be used this way too, but TAL is
kinda neat too. Still, I couldn't think of much practical use
Martijn Faassen wrote:
Right, that was my motivation too - I googled around for
javascript-based templating languages but realized there wasn't really
anything. Of course XSLT can be used this way too, but TAL is kinda neat
too. Still, I couldn't think of much practical use for this. Perhaps in
Balazs Ree wrote:
On Mon, 13 Feb 2006 18:59:32 +0100 Martijn Faassen wrote:
Jean-Marc Orliaguet wrote:
I've being working on integrating Balazs Ree's CTAL interpreter recently
(added tests, fixes, etc.). CTAL is the equivalent of TAL but for
javascript.
I just googled around for this, and
On Mon, 13 Feb 2006 18:59:32 +0100 Martijn Faassen wrote:
> Jean-Marc Orliaguet wrote:
>
>> I've being working on integrating Balazs Ree's CTAL interpreter recently
>> (added tests, fixes, etc.). CTAL is the equivalent of TAL but for
>> javascript.
>
> I just googled around for this, and couldn't
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tonico Strasser wrote:
I'm interested in your opinion about parameters for macros.
Do you think this is explicit enough?:
Or do you think explicit parameters would make things clearer?:
I don't favor "expli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tonico Strasser wrote:
> I'm interested in your opinion about parameters for macros.
>
> Do you think this is explicit enough?:
>
>
>
>
>
> Or do you think explicit parameters would make things clearer?:
>
>
> metal:with-params="lis
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
On 2/13/06, Tonico Strasser <[EMAIL PROTECTED]> wrote:
Looking forward to see explicit ZPTs soon :)
Me too. I'd also like the macros to be called rather than expanded, so
that any error messages report t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
> On 2/13/06, Tonico Strasser <[EMAIL PROTECTED]> wrote:
>
>>Looking forward to see explicit ZPTs soon :)
>
>
> Me too. I'd also like the macros to be called rather than expanded, so
> that any error messages report the error
On 2/13/06, Tonico Strasser <[EMAIL PROTECTED]> wrote:
> Looking forward to see explicit ZPTs soon :)
Me too. I'd also like the macros to be called rather than expanded, so
that any error messages report the error in the macro rather than in
an expanded main template. This should be possible if we
Tonico Strasser wrote:
Although you told me that's an anti-pattern, I'll have to use it until I
find a better pattern.
This is true. :)
I can't live without the benefit of reusing macros.
Agreed. I just hope that someone will do the work necessary to create a
better way of doing so.
--
B
Benji York wrote:
Jean-Marc Orliaguet wrote:
[snip description of cross-template communication]
that's an anti-pattern
Agreed.
Although you told me that's an anti-pattern, I'll have to use it until I
find a better pattern. I can't live without the benefit of reusing macros.
Tonico
__
Jean-Marc Orliaguet wrote:
"tal:define" is used here to pass parameters to the macro. In ZPT this
is done implicitly, which is why macros specify a list a variables that
must be defined.
In other language this is done explictly. (cf. XSLT )
If it was done explicitly in ZPT it could look like:
Tonico Strasser wrote:
(Again with the right quote, sorry.)
Jean-Marc Orliaguet wrote:
That's exactly what I'm saying: if templates did not try to create
their own data layer, the 'li_repeat' macro could get the data from
the model (instead it has to rely on cross-template communication)
t
(Again with the right quote, sorry.)
Jean-Marc Orliaguet wrote:
That's exactly what I'm saying: if templates did not try to create their
own data layer, the 'li_repeat' macro could get the data from the model
(instead it has to rely on cross-template communication)
that's an anti-pattern whic
Jean-Marc Orliaguet wrote:
Tonico Strasser wrote:
Hi Jean-Marc!
I agree that a view should not be able to modify the data model. But I
think tal:define is a must have :)
For example: I need tal:define to define names for generic macros:
The 'li_repeat' macro expects the name 'list'.
Jean-Marc Orliaguet wrote:
[snip description of cross-template communication]
that's an anti-pattern
Agreed.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/opti
Jean-Marc Orliaguet wrote:
[snip description of cross-template communication]
that's an anti-pattern
Agreed.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/opti
Tonico Strasser wrote:
Hi Jean-Marc!
I agree that a view should not be able to modify the data model. But I
think tal:define is a must have :)
For example: I need tal:define to define names for generic macros:
The 'li_repeat' macro expects the name 'list'.
Tonico
That's exactly wh
Hi Jean-Marc!
I agree that a view should not be able to modify the data model. But I
think tal:define is a must have :)
For example: I need tal:define to define names for generic macros:
The 'li_repeat' macro expects the name 'list'.
Tonico
Andreas Jung wrote:
--On 12. Februar 2006 19:18:51 +0100 Max M <[EMAIL PROTECTED]> wrote:
Title
I could write this:
Title
That's really syntactical sugar. The purpose of the tal: names is clearly
to tell the parser to do _something_ with the value of an attribute. Now
should a parser
--On 12. Februar 2006 19:18:51 +0100 Max M <[EMAIL PROTECTED]> wrote:
Title
I could write this:
Title
That's really syntactical sugar. The purpose of the tal: names is clearly
to tell the parser to do _something_ with the value of an attribute. Now
should a parser guess if the value of a
kit BLAKE wrote:
In 'normal' tal we often refactor our defines to improve efficiency.
When something is called more than once in a template, we define it at
the beginning, and then use it multiple times. This improves
performance dramatically of course.
kit
On another note, I think that tal:de
kit BLAKE wrote:
In 'normal' tal we often refactor our defines to improve efficiency.
When something is called more than once in a template, we define it at
the beginning, and then use it multiple times. This improves
performance dramatically of course.
kit
--
kit BLAKE
Infrae · infrae.com · +
Balazs Ree wrote:
Sat, 11 Feb 2006 21:03:21 +0100 keltezéssel Jean-Marc Orliaguet azt
írta:
I almost felt that something was missing, because I'm so used to inserting
"tal:define" in page templates. But now I realize that this is a mistake.
There was a discussion recently on the list about
In 'normal' tal we often refactor our defines to improve efficiency.
When something is called more than once in a template, we define it at
the beginning, and then use it multiple times. This improves
performance dramatically of course.
kit
--
kit BLAKE
Infrae · infrae.com · +31 10 243 7051
Hoeve
Sat, 11 Feb 2006 21:03:21 +0100 keltezéssel Jean-Marc Orliaguet azt
írta:
> I almost felt that something was missing, because I'm so used to inserting
> "tal:define" in page templates. But now I realize that this is a mistake.
>
> There was a discussion recently on the list about python expression
26 matches
Mail list logo
