Hi Florin,
According to HTML spec[1], using dots are allowed. It states:
"ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".")."
So Click is within the limits here.
Tackling the Velocity issue, you can access the map keys the same way
you do in Java:
$form.fields.get("address.state")
There might be other ways to address this in Velocity?
Regarding the jQuery issue, one problem is that CSS selectors only
allows a subset[2] of valid HTML characters. For example DOT "." would
be seen as a class identifier.
Solutions exist though, for example you can escape the selector e.g:
$('#form_address\\.zip'). Alternatively you can explicitly define an
ID attribute for the field you want to access through JQuery.
Wrt changing the notation the only alternative seems to use dash '-'.
But when switching back all dashes will be converted to dots. I can
imagine scenarios where a dash could in fact be part of the name and
should not be switched. My feeling is that changing notation could
lead to further problems.
bob
[1]: http://www.w3.org/TR/REC-html40/types.html#type-name
[2]: https://developer.mozilla.org/en/Underscores_in_class_and_ID_Names
florin.g wrote:
Hi,
I've avoided using the dot notation with forms, yet I've come across a
situation that would be best solved with the dot notation:
customer.address.zip matches to "form_address.zip".
The problem is that neither velocity nor jquery are happy with the dot
notation:
$form.fields.address.zip would not do for velocity;
$('#form_address.zip') would not do for jquery;
Is it possible we change the rendering of the notation as something else
than a period ("."). This notation will be switched back when velocity will
lookup for request to object mapping?
