Soy has historically tolerated map accesses on weakly-typed variables. That is, if a template declared a param $p and then did $p['some_key'] in the template body, Soy would treat $p as a map even if it wasn't statically declared as one.
This situation is changing with [] There are now two map types, `map` and `legacy_object_map`. We are trying to migrate every template in [] from `legacy_object_map` to `map`, leaving Soy with one (improved) map type. Because the two map types generate different JS code, Soy can no longer allow map accesses on weakly-typed variables. (If $p['some_key'] occurs in a template and the type of $p is unknown, Soy would not know what code to generate.)
Every parameter whose static type is unknown (`?`) but which is inferred to be a `legacy_object_map` needs to be migrated to a `map`. We are developing tools for this in [] However, as a first step, we need to migrate the subset of these params that use the legacy SoyDoc syntax to use header param syntax with a static type of `?`. (All params declared in SoyDoc are typed as unknown, and it is a compilation error to mix SoyDoc and header param syntax in the same template, so any template that declares a SoyDoc param that is inferred to be a map needs to migrate to header param syntax.)
This CL was prepared by using the tools in [] to create a list of templates declaring SoyDoc params inferred to be legacy_object_maps. This list was then fed to the existing //third_party/java_src/soy/java/com/google/template/soy/tools:ParamMigrator tool. Since this tool migrates whole files instead of individual templates, the resulting CL is a superset of the migration that is actually required. However, since the SoyDoc param syntax has been deprecated for years, and since there is little risk in migrating from one param style to another, I decided to land the superset.
This migration falls under the LSC described at https://docs.google.com/document/d/1dAl-rDMp3oL0Zh_iSTaiHICwtcbLbVIy1FQ0wXSAaHs.
Tested:
TAP --sample for global presubmit queue
[] passed FOSS tests
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188879980
This also updates to a newer version of Closure Rules and fixes a protobuf dep
compile issue.
Full description of the change:
Soy supports 2 kinds of loops:
* foreach- for iterating over items in a collection, e.g.
{foreach $item in $list}...{/foreach}
* for - for indexed iteration, e.g. {for $i in range(0, 10)}...{/for}
The reason Soy has two different loops is an accident of history; Soy didn’t use
to have a proper grammar for expressions and so the alternate ‘for...range’
syntax was added to make it possible to write indexed loops. As the grammar has
improved having the two syntaxes is no longer necessary and so we are
eliminating one of them.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182843207
*** Reason for rollback ***
Breaks the FOSS build.
We'll reincorporate this change once Closure Rules is properly updated to accommodate it.
*** Original change description ***
Change all foreach loops in Soy templates to use the for loop syntax
Soy supports 2 kinds of loops:
foreach- for iterating over items in a collection e.g. {foreach $item in $list}...{/foreach}
for - for indexed iteration e.g. {for $i in range(0, 10)}...{/for}
The reason Soy has 2 different loops is an accident of history, Soy didn’t use to have a proper grammar for expressions and so the alternate ‘for...range’ syntax was added to make it possible to write indexed loops. As the gramma...
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180961695
Soy supports 2 kinds of loops:
foreach- for iterating over items in a collection e.g. {foreach $item in $list}...{/foreach}
for - for indexed iteration e.g. {for $i in range(0, 10)}...{/for}
The reason Soy has 2 different loops is an accident of history, Soy didn’t use to have a proper grammar for expressions and so the alternate ‘for...range’ syntax was added to make it possible to write indexed loops. As the grammar has improved having the two syntaxes is no longer necessary and so we are eliminating one of them.
As of 4a7373333f or mvn release "2018-01-03" the two forms are actually aliases for one another, so the only difference is the keyword (‘for’ vs ‘foreach’), and while the foreach loop is more popular the ‘for’ terminology is more standard so we are switching everything to that.
LSC: []
Tested:
TAP sample presubmit queue
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180942763
Strict autoescaping is the default so they serve no purpose.
Design doc: []
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170725633
{css $foo} does not do anything. the correct syntax is
{css selector} (no dollar sign)
or
{css $prefix, selector}
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152375039
This feature would have been useful earlier when I was changing the TLD
state on a sandbox TLD on-the-fly for testing purposes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128088578
This change renames directories in preparation for the great package
rename. The repository is now in a broken state because the code
itself hasn't been updated. However this should ensure that git
correctly preserves history for each file.
2016-05-13 18:55:08 -04:00
Renamed from java/com/google/domain/registry/ui/soy/Forms.soy (Browse further)
