I would say: always code you JavaScript to adapt to the framework-generated ids.
However, my mental roadplan for Tapestry will be to attempt to minimize the importance of element ids; favoring instead the more modern approach of using CSS classes and page structure to identify client-side elements that require extra logic. On Mon, Dec 26, 2011 at 4:34 AM, Muhammad Gelbana <m.gelb...@gmail.com> wrote: > When I was using t5.2.6 I had a form with a select field called "method". I > had javascript code working on that field. When I updated to 5.3.1 that > field's name changed to "method_0" which broke the JS functionality. > > After debugging I found that "InternalSymbols.PRE_SELECTED_FORM_NAMES" was > injected in the "Form" component as an InternalSymbol and as the > documentation says, this is to work around some form fields naming > conflicts. > > This mail is just explain to people why would a form field of theirs would > have an id that makes it look like there are other components with the same > id (i.e. id_0, id_1...etc) > > So basically don't name your form fields to any of (* > reset,submit,select,id,method,action,onsubmit,cancel*) unless you are ready > to deal with your field using an id assigned to it be tapestry. It's > incremental so it's predictable. In my case I had a "method_0" select > component. > > I have a question to tapestry developers. Where exactly is the hard coded > value for that internal symbol ? Debugging was the easiest way to find it > out. > > -- > *Regards,* > *Muhammad Gelbana > Java Developer* -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
