Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
When I started working on a attribute template language (ATL)
proposal, it was obvious to me that it should be attribute name
driven. So why did I end up proposing a content driven one? While the
attribute driven is atractive for very simple
Vadim Gritsenko wrote:
for(var=name,begin=expr,end=expr,step=expr)
---
Is it necessary? Current jxtg does not have it (IIRC).
it does.
--
Leszek Gawron [EMAIL PROTECTED]
Project Manager
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Just a reminder; before you guys start implementing one or another
template language, could we have [VOTE] for one of the variants, have
[PROPOSAL], or at least [SUMMARY]? :)
We are discussing several tasks:
1) Refactoring of JXTG so that that
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
snip what=thing discussed in another mail/
Here, I just want to comment that I find way more intuitive and user
friendly following constructs:
if(test)
--
example:
div do=if(count(cart/item) == 0)
div t:if=cart/item
and
div
Daniel Fagerstrom wrote:
snip/
When I started working on a attribute template language (ATL)
proposal, it was obvious to me that it should be attribute name
driven. So why did I end up proposing a content driven one? While the
attribute driven is atractive for very simple examples it IMO very
On Dec 7, 2004, at 4:18 AM, Daniel Fagerstrom wrote:
Refactoring JXTG
I think everything starts here. Once this gets refactored the
opportunities for further development should become apparent. There is
nothing terribly wrong with JXTG, except that it is a monolithic class
with
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
snip/
We also need:
- some script compiler directives i.e. for cache control (as in JXTG)
Seem reasonable, sugest some mechanism.
ignore do=processingInstruction( 'cache-key', $cacheKey )/ if we
want the
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
snip/
We also need:
- some script compiler directives i.e. for cache control (as in JXTG)
Seem reasonable, sugest some mechanism.
ignore do=processingInstruction( 'cache-key',
Le 7 déc. 04, à 18:54, Sylvain Wallez a écrit :
...(hearing Stefano coming behind me, ready to shout FS!!! in my
ears...)
Nahh...his detector exploded yesterday, don't worry.
...Now going back to the annotated-HTML-to-XSL compiler that we
(Anyware) wrote many years ago, it allows
Daniel Fagerstrom wrote:
Just a reminder; before you guys start implementing one or another template
language, could we have [VOTE] for one of the variants, have [PROPOSAL], or at
least [SUMMARY]? :)
Here, I just want to comment that I find way more intuitive and user friendly
following
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
I like this idea very much. It would be a shame if the quirks of
Dreamweaver should force everyone to use an awkward syntax.
The attribute driven synatax is new to me so I don't know if I find it
awkward or not, I'll need to see some larger
Reinhard Poetz wrote:
But the Dreamweaver usecase is a valid one (It was me who started a
discussion about this in May after attenting a Tapestry seminar at a
conference) and so we should support it.
Now, having them cohexist in the page smells like FS, though ;-)
Can't agree more.
What would
Roy G. Biv wrote:
Any prohibition on (non-HTML) namespaced tags would imply to me that
arbitrary namespaced attributes would be a no-no in Dreamweaver as
well. Stefano, as I haven't ever used Dreamweaver for more than ten
minutes, is this limitation a rendering issue or data entry issue? I
Leszek Gawron wrote:
Reinhard Poetz wrote:
But the Dreamweaver usecase is a valid one (It was me who started a
discussion about this in May after attenting a Tapestry seminar at a
conference) and so we should support it.
Now, having them cohexist in the page smells like FS, though ;-)
Can't
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
But the Dreamweaver usecase is a valid one (It was me who started a
discussion about this in May after attenting a Tapestry seminar at a
conference) and so we should support it.
Now, having them cohexist in the page smells like
Leszek Gawron wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
But the Dreamweaver usecase is a valid one (It was me who started a
discussion about this in May after attenting a Tapestry seminar at a
conference) and so we should support it.
Now, having them cohexist in
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
macro(name,param-name,...,param-name)
---
example:
table do=macro(mytable,list,td-class)
tr do=forEach($list)
td class=${$class}${item}/td
/tr
/table
We also need an evalBody as
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
I like this idea very much. It would be a shame if the quirks of
Dreamweaver should force everyone to use an awkward syntax.
The attribute driven synatax is new to me so I don't know if I find it
awkward or not, I'll need to see some larger
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
snip/
We also need:
- some script compiler directives i.e. for cache control (as in JXTG)
Seem reasonable, sugest some mechanism.
ignore do=processingInstruction( 'cache-key', $cacheKey )/ if we
want the directive to remove
On Dec 5, 2004, at 8:04 AM, Leszek Gawron wrote:
Fine by me. The only concern is the performance here. Macro would have
to be played, output recorded and after that omitTag invoked. I'd
rather do it otherwise.
As is usually, my advice is that unless you know what the performance
hit will be in
On Dec 5, 2004, at 10:02 AM, Daniel Fagerstrom wrote:
Your alarm might have been desensitized by our continuos stream of FS
;) Actually it would be boring if you were easy to predict.
I really think that it makes sense to have two different syntaxes,
one that uses elements and another one that
Leszek Gawron wrote:
Reinhard Poetz wrote:
But the Dreamweaver usecase is a valid one (It was me who started a
discussion about this in May after attenting a Tapestry seminar at a
conference) and so we should support it.
Now, having them cohexist in the page smells like FS, though ;-)
Can't
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
I like this idea very much. It would be a shame if the quirks of
Dreamweaver should force everyone to use an awkward syntax.
The attribute driven synatax is new to me so I don't know if I find
it awkward or not, I'll need
Glen Ezkovich wrote:
On Dec 5, 2004, at 10:02 AM, Daniel Fagerstrom wrote:
Your alarm might have been desensitized by our continuos stream of FS
;) Actually it would be boring if you were easy to predict.
I really think that it makes sense to have two different syntaxes,
one that uses elements
On Dec 5, 2004, at 11:59 AM, Stefano Mazzocchi wrote:
Glen Ezkovich wrote:
On Dec 5, 2004, at 10:02 AM, Daniel Fagerstrom wrote:
Your alarm might have been desensitized by our continuos stream of
FS ;) Actually it would be boring if you were easy to predict.
I really think that it makes sense to
Stefano Mazzocchi wrote:
All I ask from a template language:
1) something that HTML designers can edit with Dreamweaver
2) something that doesn't use namespaced tags to identify dynamic
scopes (clashes with #1)
3) something that doesn't use the name taglib
That's pretty much all you have to
On Sat, 4 Dec 2004, Daniel Fagerstrom wrote:
snip...
if(test)
--
example:
div do=if(count(cart/item) == 0)
Your cart is empty
div
How would you implement choose/when?
snip...
Several directives
--
So, how do we handle multiple directives for one
Daniel Fagerstrom wrote:
macro(name,param-name,...,param-name)
---
example:
table do=macro(mytable,list,td-class)
tr do=forEach($list)
td class=${$class}${item}/td
/tr
/table
We also need an evalBody as in JXTG. And maybe we should have a
possibilty
Jonas Ekstedt wrote:
Several directives
--
So, how do we handle multiple directives for one element? We could
handle the TAL example above like:
p
do=let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)
Ex Text
/p
Isn't there a risk that attribute
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
macro(name,param-name,...,param-name)
---
example:
table do=macro(mytable,list,td-class)
tr do=forEach($list)
td class=${$class}${item}/td
/tr
/table
We also need an evalBody as in JXTG. And maybe we
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
All I ask from a template language:
1) something that HTML designers can edit with Dreamweaver
2) something that doesn't use namespaced tags to identify dynamic
scopes (clashes with #1)
3) something that doesn't use the name taglib
That's
Roy G. Biv wrote:
2. Namespaced tag or attribute: may not be compatible with Dreamweaver
(strikes me as a serious limitation that needs to be addressed by the
Dreamweaver developers IMHO), but can guarantee well-formedness.
Nevermind. Forget I said this. Dreamweaver supports namespaced
Roy G. Biv wrote:
Daniel Fagerstrom wrote:
snip/
I as well. In addition, I think that the optimum template language
would be as close to the appearance of the output document as possible.
(Yet another reason I don't personally care for explicit forEach, if and
chose elements; they make it
Daniel Fagerstrom wrote:
I like this idea very much. It would be a shame if the quirks of
Dreamweaver should force everyone to use an awkward syntax.
The attribute driven synatax is new to me so I don't know if I find it
awkward or not, I'll need to see some larger examples. Anyway, we have a
Daniel Fagerstrom wrote:
Stefano's focus seem to be on HTML.
For the record: my focus is on having a template language for cocoon
that is as powerful as XSP but avoids all the problems.
Also, I think that XHTML markup offers the best possible usecase of how
that template language should work.
Stefano Mazzocchi wrote:
For the record: my focus is on having a template language for cocoon
that is as powerful as XSP but avoids all the problems.
Is that realistic? I can see logicsheets, but XSP was arbitrary Java
code. I find it hard to believe that *anything* will be as
Roy G. Biv wrote:
Stefano Mazzocchi wrote:
For the record: my focus is on having a template language for cocoon
that is as powerful as XSP but avoids all the problems.
Is that realistic? I can see logicsheets, but XSP was arbitrary Java
code. I find it hard to believe that *anything* will be
On Dec 4, 2004, at 11:40 PM, Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Stefano's focus seem to be on HTML.
For the record: my focus is on having a template language for cocoon
that is as powerful as XSP but avoids all the problems.
Then it won't be as powerful ;-) The power is not needed.
38 matches
Mail list logo
