> Seems like for in only works with range and foreach creates a for (;;) > that assumes an array. Is there no way to iterate over a key value > object?
> {forin $key, $value in $map} > <li>{$key}: {$value} > {ifempty} > No pairings! > {/forin}
> On Tue, Oct 19, 2010 at 7:20 PM, Bjorn Tipling <bjorn.tipl...@gmail.com>wrote:
>> Seems like for in only works with range and foreach creates a for (;;) >> that assumes an array. Is there no way to iterate over a key value >> object?
On Wed, Oct 20, 2010 at 12:15 PM, Tom Ball <tb...@google.com> wrote: > Perhaps a plugin function that returns the keys from a map as a list? Then > you could do something like:
> {foreach $key in keys($map)} > ... > {/foreach}
> Tom
> On Wed, Oct 20, 2010 at 7:39 AM, Michael Bolin <bolinf...@gmail.com>wrote:
>> {forin $key, $value in $map} >> <li>{$key}: {$value} >> {ifempty} >> No pairings! >> {/forin}
>> On Tue, Oct 19, 2010 at 7:20 PM, Bjorn Tipling <bjorn.tipl...@gmail.com>wrote:
>>> Seems like for in only works with range and foreach creates a for (;;) >>> that assumes an array. Is there no way to iterate over a key value >>> object?
> Perhaps a plugin function that returns the keys from a map as a list? Then > you could do something like: > {foreach $key in keys($map)} > ... > {/foreach} > Tom
This seems like a good idea. If it becomes a base function, then it would be a good optimization target resolving to a simple JS for..in loop when compiled to JS.
>> {forin $key, $value in $map} >> <li>{$key}: {$value} >> {ifempty} >> No pairings! >> {/forin}
>> On Tue, Oct 19, 2010 at 7:20 PM, Bjorn Tipling <bjorn.tipl...@gmail.com> >> wrote:
>>> Seems like for in only works with range and foreach creates a for (;;) >>> that assumes an array. Is there no way to iterate over a key value >>> object?
I think Tom's suggestion would be a good idea. Seems like a common use
case. If by destructuring you mean assigning two values at once
(something like maybe for k, v in iteritems(map)), that's also a
pretty nice.
On Oct 20, 10:28 am, Mike Samuel <mikesam...@gmail.com> wrote:
> > Perhaps a plugin function that returns the keys from a map as a list? Then
> > you could do something like:
> > {foreach $key in keys($map)}
> > ...
> > {/foreach}
> > Tom
> This seems like a good idea.
> If it becomes a base function, then it would be a good optimization
> target resolving to a simple JS for..in loop when compiled to JS.
> >> On Tue, Oct 19, 2010 at 7:20 PM, Bjorn Tipling <bjorn.tipl...@gmail.com>
> >> wrote:
> >>> Seems like for in only works with range and foreach creates a for (;;)
> >>> that assumes an array. Is there no way to iterate over a key value
> >>> object?
If this feature were to exist, how would you guys expect the entries
to be ordered? Would we just iterate based on the underlying map
implementation (in either JS or Java) and return the entries in
whatever arbitrary order? Note that this would not guarantee same
behavior across multiple runs, nor the same behavior in JS and Java.
Or would we always sort the entries alphabetically by key?
I don't see one option as clearly better than the other. Of course we
can make it more complicated by allowing the user to choose which
option, or even allowing the user to supply a sorting function
somehow. But the usefulness of the feature may not be worth it for
the extra complexity.
I think if a developer needs sorted data, then they should use a list instead of a map. That said, it wouldn't hurt if the keys were alphabetically sorted first. If the character sets are the same, should such a sort give the same results with Java or JavaScript?
On Tue, Oct 26, 2010 at 2:20 PM, Kai Huang <kai.hu...@gmail.com> wrote: > If this feature were to exist, how would you guys expect the entries > to be ordered? Would we just iterate based on the underlying map > implementation (in either JS or Java) and return the entries in > whatever arbitrary order? Note that this would not guarantee same > behavior across multiple runs, nor the same behavior in JS and Java. > Or would we always sort the entries alphabetically by key?
> I don't see one option as clearly better than the other. Of course we > can make it more complicated by allowing the user to choose which > option, or even allowing the user to supply a sorting function > somehow. But the usefulness of the feature may not be worth it for > the extra complexity.
> I think if a developer needs sorted data, then they should use a list > instead of a map. That said, it wouldn't hurt if the keys were > alphabetically sorted first. If the character sets are the same, should > such a sort give the same results with Java or JavaScript?
There is no iteration order specified for JavaScript objects, but EcmaScript harmony will probably specify insertion order within each prototype chain layer which is the same as LinkedHashMaps in java.
Whould only own properties be returned in JS for compatibility with Java?
> On Tue, Oct 26, 2010 at 2:20 PM, Kai Huang <kai.hu...@gmail.com> wrote:
>> If this feature were to exist, how would you guys expect the entries >> to be ordered? Would we just iterate based on the underlying map >> implementation (in either JS or Java) and return the entries in >> whatever arbitrary order? Note that this would not guarantee same >> behavior across multiple runs, nor the same behavior in JS and Java. >> Or would we always sort the entries alphabetically by key?
>> I don't see one option as clearly better than the other. Of course we >> can make it more complicated by allowing the user to choose which >> option, or even allowing the user to supply a sorting function >> somehow. But the usefulness of the feature may not be worth it for >> the extra complexity.
Has anyone tried the proposed solution that returns the keys from the
map as a list?
The soy parser does not seem to like using functions as the data ref
inside of the foreach command.
I have a working keys function and the compilation fails in various
ways:
> {foreach $name in keys($foos)}
Invalid data reference in 'foreach' command text "$name in
keys($foos)".
> {foreach $name in {keys($foos)}}
Left brace '{' not allowed within a Soy tag delimited by single braces
(consider using double braces to delimit the Soy tag)
> {{foreach $name in {keys($foos)}}}
Last character in a Soy tag must not be a brace character (consider
inserting a space after the brace character)
etc
On Oct 26, 6:44 pm, Mike Samuel <mikesam...@gmail.com> wrote:
> > I think if a developer needs sorted data, then they should use a list
> > instead of a map. That said, it wouldn't hurt if the keys were
> > alphabetically sorted first. If the character sets are the same, should
> > such a sort give the same results with Java or JavaScript?
> There is no iteration order specified for JavaScript objects, but
> EcmaScript harmony will probably specify insertion order within each
> prototype chain layer which is the same as LinkedHashMaps in java.
> Whould only own properties be returned in JS for compatibility with Java?
> > Tom
> > On Tue, Oct 26, 2010 at 2:20 PM, Kai Huang <kai.hu...@gmail.com> wrote:
> >> If this feature were to exist, how would you guys expect the entries
> >> to be ordered? Would we just iterate based on the underlying map
> >> implementation (in either JS or Java) and return the entries in
> >> whatever arbitrary order? Note that this would not guarantee same
> >> behavior across multiple runs, nor the same behavior in JS and Java.
> >> Or would we always sort the entries alphabetically by key?
> >> I don't see one option as clearly better than the other. Of course we
> >> can make it more complicated by allowing the user to choose which
> >> option, or even allowing the user to supply a sorting function
> >> somehow. But the usefulness of the feature may not be worth it for
> >> the extra complexity.
Yeah, right now the 'foreach' command only recognizes a data reference
in the data="..." attribute. But off the top of my head, I don't
think there's any reason that it can't be changed to accept an
arbitrary expression.
On Nov 5, 8:11 am, Dolapo Falola <dol...@gmail.com> wrote:
> Has anyone tried the proposed solution that returns the keys from the
> map as a list?
> The soy parser does not seem to like using functions as the data ref
> inside of the foreach command.
> I have a working keys function and the compilation fails in various
> ways:
> > {foreach $name in keys($foos)}
> Invalid data reference in 'foreach' command text "$name in
> keys($foos)".
> > {foreach $name in {keys($foos)}}
> Left brace '{' not allowed within a Soy tag delimited by single braces
> (consider using double braces to delimit the Soy tag)
> > {{foreach $name in {keys($foos)}}}
> Last character in a Soy tag must not be a brace character (consider
> inserting a space after the brace character)
> etc
> On Oct 26, 6:44 pm, Mike Samuel <mikesam...@gmail.com> wrote:
> > > I think if a developer needs sorted data, then they should use a list
> > > instead of a map. That said, it wouldn't hurt if the keys were
> > > alphabetically sorted first. If the character sets are the same, should
> > > such a sort give the same results with Java or JavaScript?
> > There is no iteration order specified for JavaScript objects, but
> > EcmaScript harmony will probably specify insertion order within each
> > prototype chain layer which is the same as LinkedHashMaps in java.
> > Whould only own properties be returned in JS for compatibility with Java?
> > > Tom
> > > On Tue, Oct 26, 2010 at 2:20 PM, Kai Huang <kai.hu...@gmail.com> wrote:
> > >> If this feature were to exist, how would you guys expect the entries
> > >> to be ordered? Would we just iterate based on the underlying map
> > >> implementation (in either JS or Java) and return the entries in
> > >> whatever arbitrary order? Note that this would not guarantee same
> > >> behavior across multiple runs, nor the same behavior in JS and Java.
> > >> Or would we always sort the entries alphabetically by key?
> > >> I don't see one option as clearly better than the other. Of course we
> > >> can make it more complicated by allowing the user to choose which
> > >> option, or even allowing the user to supply a sorting function
> > >> somehow. But the usefulness of the feature may not be worth it for
> > >> the extra complexity.
Hey, has anyone come up with a decent solution to this problem? It's really frustrating having to transform my datatypes before using it with every soy template, especially when I'm converting code from a different templating engine.
If not, where's the best place to start on writing a plugin? Examples I can follow? I've only been using the javascript version and don't know the java API at all. I'm happy to write my own foreach if necessary just to get something usable working.
If your intent is to modify 'foreach' such that it accepts an
arbitrary expression to iterate over (such as the plugin function that
Dolapo was trying to use above), then your modification would not be a
plugin. You'd have to modify the compiler code itself. But it
wouldn't be a difficult change. (If you want to do it, see
ForeachNode, where you'll want to change the usage of
ExpressionParser.parseDataReference() to
ExpressionParser.parseExpression() instead.)
Sorry we can't just push out a release for you right now (since inside
Google, this modification you desire is already done). We just don't
have the bandwidth right now to prepare a release, which entails a lot
of other issues. We may be able to push out a new release sometime
next quarter (Apr-Jun). We'll also try to target being able to accept
external contributions by end of the following quarter (Jul-Sep).
On Mar 28, 4:54 pm, Charles Ma <chuck...@gmail.com> wrote:
> Hey, has anyone come up with a decent solution to this problem? It's really
> frustrating having to transform my datatypes before using it with every soy
> template, especially when I'm converting code from a different templating
> engine.
> If not, where's the best place to start on writing a plugin? Examples I can
> follow? I've only been using the javascript version and don't know the java
> API at all. I'm happy to write my own foreach if necessary just to get
> something usable working.
Is there an official solution for this or is it still a case of rolling our own?
I want to be able to build a form based on an arbitrary map as per the above.
e.g. something like:
{foreach $key in keys($myMap)} {$key} = {value($myMap, $key)} {/foreach}
Seems like a pretty fundamental thing so I'm a little surprised it's not there by default and this thread is a tad old.
The keys($map) function seems to exist and works under normal circumstances, but not within a foreach, and I can't see anything that I could use for the 'value' part.
On Tuesday, 29 March 2011 11:36:01 UTC+11, Kai Huang wrote:
> If your intent is to modify 'foreach' such that it accepts an > arbitrary expression to iterate over (such as the plugin function that > Dolapo was trying to use above), then your modification would not be a > plugin. You'd have to modify the compiler code itself. But it > wouldn't be a difficult change. (If you want to do it, see > ForeachNode, where you'll want to change the usage of > ExpressionParser.parseDataReference() to > ExpressionParser.parseExpression() instead.)
> Sorry we can't just push out a release for you right now (since inside > Google, this modification you desire is already done). We just don't > have the bandwidth right now to prepare a release, which entails a lot > of other issues. We may be able to push out a new release sometime > next quarter (Apr-Jun). We'll also try to target being able to accept > external contributions by end of the following quarter (Jul-Sep).
> On Mar 28, 4:54 pm, Charles Ma <chuck...@gmail.com> wrote: > > Hey, has anyone come up with a decent solution to this problem? It's > really > > frustrating having to transform my datatypes before using it with every > soy > > template, especially when I'm converting code from a different > templating > > engine.
> > If not, where's the best place to start on writing a plugin? Examples I > can > > follow? I've only been using the javascript version and don't know the > java > > API at all. I'm happy to write my own foreach if necessary just to get > > something usable working.
> Seems like a pretty fundamental thing so I'm a little surprised it's not > there by default and this thread is a tad old.
> The keys($map) function seems to exist and works under normal > circumstances, but not within a foreach, and I can't see anything that I > could use for the 'value' part.
> On Tuesday, 29 March 2011 11:36:01 UTC+11, Kai Huang wrote:
>> If your intent is to modify 'foreach' such that it accepts an >> arbitrary expression to iterate over (such as the plugin function that >> Dolapo was trying to use above), then your modification would not be a >> plugin. You'd have to modify the compiler code itself. But it >> wouldn't be a difficult change. (If you want to do it, see >> ForeachNode, where you'll want to change the usage of >> ExpressionParser.parseDataReference() to >> ExpressionParser.parseExpression() instead.)
>> Sorry we can't just push out a release for you right now (since inside >> Google, this modification you desire is already done). We just don't >> have the bandwidth right now to prepare a release, which entails a lot >> of other issues. We may be able to push out a new release sometime >> next quarter (Apr-Jun). We'll also try to target being able to accept >> external contributions by end of the following quarter (Jul-Sep).
>> On Mar 28, 4:54 pm, Charles Ma <chuck...@gmail.com> wrote: >> > Hey, has anyone come up with a decent solution to this problem? It's >> really >> > frustrating having to transform my datatypes before using it with every >> soy >> > template, especially when I'm converting code from a different >> templating >> > engine.
>> > If not, where's the best place to start on writing a plugin? Examples I >> can >> > follow? I've only been using the javascript version and don't know the >> java >> > API at all. I'm happy to write my own foreach if necessary just to get >> > something usable working.
>> Seems like a pretty fundamental thing so I'm a little surprised it's not >> there by default and this thread is a tad old.
>> The keys($map) function seems to exist and works under normal >> circumstances, but not within a foreach, and I can't see anything that I >> could use for the 'value' part.
>> On Tuesday, 29 March 2011 11:36:01 UTC+11, Kai Huang wrote:
>>> If your intent is to modify 'foreach' such that it accepts an >>> arbitrary expression to iterate over (such as the plugin function that >>> Dolapo was trying to use above), then your modification would not be a >>> plugin. You'd have to modify the compiler code itself. But it >>> wouldn't be a difficult change. (If you want to do it, see >>> ForeachNode, where you'll want to change the usage of >>> ExpressionParser.parseDataReference() to >>> ExpressionParser.parseExpression() instead.)
>>> Sorry we can't just push out a release for you right now (since inside >>> Google, this modification you desire is already done). We just don't >>> have the bandwidth right now to prepare a release, which entails a lot >>> of other issues. We may be able to push out a new release sometime >>> next quarter (Apr-Jun). We'll also try to target being able to accept >>> external contributions by end of the following quarter (Jul-Sep).
>>> On Mar 28, 4:54 pm, Charles Ma <chuck...@gmail.com> wrote: >>> > Hey, has anyone come up with a decent solution to this problem? It's >>> really >>> > frustrating having to transform my datatypes before using it with >>> every soy >>> > template, especially when I'm converting code from a different >>> templating >>> > engine.
>>> > If not, where's the best place to start on writing a plugin? Examples >>> I can >>> > follow? I've only been using the javascript version and don't know the >>> java >>> > API at all. I'm happy to write my own foreach if necessary just to get >>> > something usable working.
