Already had this problem and I'm still asking myself if it is a good thing to not let the developper controls the clientId. I tend to think it should be the matter of the developper, not of the framework.
On Tue, Dec 15, 2009 at 10:28 PM, Benny Law <benny.mk....@gmail.com> wrote: > Hi, sorry for jumping in, but I ran into this before myself. I still don't > quite understand the need for T5 to do this though: If the zone is being > replaced during the update, how can element IDs be duplicated inside the > zone? Losing control over element IDs is a bit inconvenient, and that's one > of the (numerous) things I disliked about ASP.NET. > > Thanks for any light you can shed on this. > > Benny > > On Tue, Dec 15, 2009 at 4:20 PM, Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > Em Tue, 15 Dec 2009 19:07:49 -0200, Gunnar Eketrapp < > > gunnar.eketr...@gmail.com> escreveu: > > > > Hi! > >> > > > > Hi! > > > > Is there any way to prevent T5 from adding these numbers. The initally > >> fields have been replaced so it should be safe to reuse the id names !!! > >> > > > > I guess not. This is Tapestry trying to avoid having more than one > element > > with the same id. > > Hint: use the class attribute instead of id in this case. > > > > -- > > Thiago H. de Paula Figueiredo > > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > > and instructor > > Owner, software architect and developer, Ars Machina Tecnologia da > > Informação Ltda. > > http://www.arsmachina.com.br > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >
