cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD √Čric <eric.burgh...@systheo.com>
Subject Re: Variable Asignment in JXTG (was: xml languages)
Date Sun, 23 Jan 2005 17:06:27 GMT
Daniel Fagerstrom wrote:

> <jx:forEach items="#{$node[@path]}">
> ...
> 
> But it wasn't clear to me what the use case does.
> 
>> I also had several
>> cases where I wanted the numbering to be consistent across several
>> forEach calls and also had to implement hacks.
>

Couldn't say better :-). That's a good abstract of what this hack is
supposed to do.

> Can possibly be done by adding count($node[@path]) to the counter.
>

I cut off too many as well as too few lines from my "real" use case :-)
sorry. But no i can't do that. ;-(

> I'm certain that you can find cases that not are solved with this. The
> question is how much of a programming language we want our template
> language to be, and my opinion is that we should contain as little
> "programming" constructs as possible while still being usable as a view.
> We must of course discuss where we should draw the line. But I would go
> for less. WDOT?
>

I think that jx:template is already a full featured programming language
(turing's machine). Anyway, what we can't do natively, we can do it with
hacks. For me everything that could potentialy minimizing the need of such
hacks is good for the "language".

>>> Another possibility is to let set asign the value to the first
>>> variable binding with the same name that it finds when the stack is
>>> searched, instead of creating a new binding at the top of the stack if
>>> the name doesn't exist on the top of the stack. If we go for this we
>>> need two constructions one that declare and possibly gives an intial
>>> value to a variable in the current context and one that binds the
>>> uppermost occurance of the name, a jx:declare and a jx:set e.g.
>>>
>>> Also we would need to change the API and behaviour of
>>> ExpressionContext so that we both have a declare and a set method.
>>> This should probably be done anyway.
>>>
>>> WDYT?
>>>
>>> /Daniel
>>>
>> I prefer the second solution. The only thing to make the use case work
>> is the ability to set the variable without implicit declaration.
>>

+1. because i don't feel like facing a functionnal programming language when
i look to jxtemplate, and adding such a declaration could be confusing for
the hardcore ones.

>> One more question: should jx:set automatically declare if there is no
>> previous declaration? I think yes.
>> 
>> When we reach an agreement I can implement it as it looks quite
>> straightforward.
> 
> Thinking a little bit more about it, we can't change the current
> behavoiur of jx:set in the indicated dirresction, it will break peoples
> templates and we don't want that.
>

True ! I see 2 solutions:
- adding an 1.0 compatibility argument to jxtg 2.0
- add the new construction and deprecate jx:set 

> I suggest that (given that we decide to go the "assignment" way, that we
> introduce two new constructions: jx:define (or declare, let, variable
> etc) and jx:assign. jx:define introduces a new variable in the current
> context and give it an initial value, it is an error to use jx:define
> for the same variable two times in the same context. jx:asign assigns
> the value of a previous declared variable and it is an error to assign
> an undefined variable. I prefer to not have any implicit declaration of
> undefined variable from jx:assign.
> 
>  From an implementation POV the ExpressionContext must be extended with
> new methods for assignment and declaration of variables as the put
> instruction supports the current jx:set behaviour.
>

Great (Y).

> /Daniel



Mime
View raw message