Hi all,
Let me ask a question: have anyone managed to propagate “name” attribute value of input field objects from Vaadin model to actual HTML page? The thing is that I can’t seem to find “name” attribute equivalent on TextField model in the first place. Right?
What worries me here is that form filling becomes painful as browser’s inbuilt history/autocomplete feature never kicks in for fields lacking “name” attribute.
Thanks,
Tomas
A valid concern. But if my belief is correct, browsers treat the name and id attributes quite the same (not with radio groups, but with other form elements). If this is the case, you could use the debug id (
Component.setDebugId(String id)
) for that purpose. Yes, the method name is a bit misleading, but it should produce the given string as the element id in the browser.
Another concern is that I’m not sure how well current generation browsers handle automatic form filling with dynamically, JavaScript generated elements. The automatic filling you be fired up before the elements are added to the DOM…
Thanks for response.
As for the Id attribute tip, I have only tested that in FF3 with not good outcome. History based client-side autocomplete (dblckick on input field) didn’t work. Have managed to manually insert name attribute to DOM and autocomplete didn’t work on it either.
You’re probably right with comment on current browser’s behavior. It might be that autocomplete is only intended to work with conventionally submitted, non-AJAX forms. Oh well, this turns out to be harder stuff than I initially expected it to be. 
Try to look into LoginForm (I hope this is correct name).
It uses static html trick to enable browser recognition of login form.
Not the simplest solution, but probably it will guide you to some better one
Thanks Vyacheslav. However after having first look I am afraid it may not be suitable for my needs.
As for the Id attribute vs Name attribute:
I have found the Id attribute seem to be sufficient for having autocomplete feature working, at least in FF. Though only one-way fashion in AJAX. It binds to historically learned values and offers drop-down list, but I guess missing submit call prevents browser from learning newly entered values. That confirms name attribute’s not really neccessary as I have originally claimed in this thread.
Well at worst case, I could focus on server-side autocomplete…
On FF with firebug, it worked for me. I set the name to something common like “username” and got all the suggestions.
Sounds reasonable. If that’s true, it seems as it’s not possible for vaadin (in a decent way) to support that
Nevertheless, I’d like to see the setName() (or setHTMLName(), or something similar) method. For example, if a field is called “email” it’s very likely that the user gets his E-Mail suggested as he entered it somewhere else before.
Also, we never know: Maybe the browser programmers change the conditions the data is stored in history or not, as the number of AJAX applications grows more and more. We should ask FF developers.
Btw. setDebugId() is not an alternative for setName() (at most a workaround). IDs should be - as the name implies - unique. But maybe the applications, for example, wants to display more than one e-mail field.
Correct, me too (once I used common name). It even works to an extent that texts previously learned from input field [name=“username”]
are being suggested to input fields [id=“username”]
.
No new texts are being added to suggestion database which is a major pain at this moment. It may change one day though 
Agreed. There’s no harm in having one extra property mapped to HTML code. We may eventually get it from Vaadin guys in the future assuming there’s enough demand for it