Yes - this all seems reasonable now...
Let's make sure we propagate it back up to the spec group.
On Wed, Jul 15, 2009 at 1:05 PM, Adam Winer <awi...@gmail.com> wrote:
> On Wed, Jul 15, 2009 at 9:45 AM, Lev Epshteyn<le...@google.com> wrote:
> > Hmmm... Just after sending that, I realized that Cur can change during
> > execution, which may or may not be what we want.
> >
> > What's the expected output here:
> >
> > <div>
> > <osx:Variable key="foo" value="outer"/>
> > ${foo}
> > <os:Repeat expression="[1, 2]">
> > ${foo}
> > <osx:Variable key="foo" value="inner${Context.Index}"/>
> > ${foo}
> > </os:Repeat>
> > ${foo}
> > </div>
> >
> > Looking at this, I would expect:
> >
> > outer
> > outer inner0
> > outer inner1
> > outer
>
> Depends on how whether we've defined a new "Element" scope or not.
>
> > The My implementation would yield
> >
> > outer
> > outer inner0
> > inner0 inner1
> > inner1
>
> Yes, which seems fine. This is a fringe case.
>
> Also, BTW: having osx:Variable "escape" a Repeat could actually be very
> useful:
>
> <div>
> <os:Repeat expression="...">
> ...
> <osx:Variable key="last" value="${Cur}"/>
> </os:Repeat>
>
> The last value was ${last}.
> </div>
>
> You could even use this to compute sums:
>
> <os:Repeat expression="${listOfIntegers}">
> <osx:Variable key="sum" value="${sum + Cur}"/>
> </os:Repeat>
>
> The total is ${sum}.
>
> > The Cur implementation will probably give us
> >
> > outer
> > [undefined] inner0
> > [undefined] inner1
> > outer
>
> Yeah, which is just bad. os:Repeat should not blow away osx:Variable.
>
> -- Adam
>
> > On Wed, Jul 15, 2009 at 12:33 PM, Lev Epshteyn <le...@google.com> wrote:
> >>
> >>
> >> On Wed, Jul 15, 2009 at 12:28 PM, Adam Winer <awi...@gmail.com> wrote:
> >>>
> >>> On Wed, Jul 15, 2009 at 8:52 AM, <le...@google.com> wrote:
> >>> > This implementation seems to define the variable for the entire
> >>> > invocation scope of a template (rather than scoped to the parent
> >>> > element
> >>> > of the <osx:Variable> tag as was initially proposed on the discussion
> >>> > thread.
> >>>
> >>> This implements Christopher Cole's spec suggestion of using My (see
> >>> goosemanjack's message from June 30) . I see the confusion: you
> >>> said "I like this idea", responding to Lane's message, but temporally
> >>> after Christopher's e-mail. So I thought you were +1'ing
> >>> Christopher's proposal, and when I said "I agree, this is good", I
> >>> meant Christopher's suggestion.
> >>>
> >>> > http://codereview.appspot.com/91118/diff/1/39
> >>> > File
> >>> >
> >>> >
> java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/tags/VariableTagHandler.java
> >>> > (right):
> >>> >
> >>> > http://codereview.appspot.com/91118/diff/1/39#newcode48
> >>> > Line 48: processor.getTemplateContext().getMy().put(key, value);
> >>> > I think putting the variable into Cur is more appropriate than My,
> >>> > since
> >>> > My is used to access XML attributes and Cur is used to access runtime
> >>> > data.
> >>>
> >>> It's too restrictive to think of "My" in that way. It's just "the
> >>> scope that is limited to a tag invocation".
> >>
> >> Fair enough, but still, changing the invocation params at runtime
> doesn't
> >> seem like the right approach.
> >>
> >> <osx:Variable key="foo" value="..."/> should allow the use of ${foo}
> with
> >> the new value, but not change ${My.foo} I don't think.
> >>
> >> Thus I believe changing the ${Cur} value is more appropriate here, as
> this
> >> is more dynamic (such as in loops)
> >>
> >>>
> >>> >
> >>> > http://codereview.appspot.com/91118
> >>> >
> >>
> >
> >
>
