it is not just repeaters its also panels, if i put 2 date picker panels for example on the form then that panel has html that also can have the same id
also the markup id is not really know until the first render so that is also a bit of a problem (you cant call getMarkupId() somewhere in your constructor code because then the markup id cant be get yet) wicket doesnt replace just all the ids only if we have to use it (in ajax behaviors) johan On Thu, Mar 6, 2008 at 10:33 PM, JP Saraceno < [EMAIL PROTECTED]> wrote: > > One of the reasons that made me choose wicket was actually his ability to > be > non-intrusive of the HTML. Actually I think I remember J. Locke saying > that > the very motivation behind having a special wicket-id attribute instead of > using directly the HTML id attribute was not to mess with it. > > Having wicket taking ownership of the IDs by default makes very hard to do > stuff outside wicket control (like css/javascript work, but also Selenium > web testing for example). That reminds me a lot to the things I dislike > the > most about the .NET framework. > > One can have many technologies working over the HTML in a web dev > scenario, > and all of them will rely on the ability to do id-based stuff. Not > understanding this is not understanding web development IMHO. > > CSS id selectors are very different than class ones, both conceptually and > in practice (i.e. the way browsers handle it). > > You should also consider migration path, as this change can make entire > applications to break, and there seems not to be a solution that doesn't > involve writing a line of code for every component that you were relying > on > its id attribute. > > The change on this policy seems derived from an implementation issue > rather > than a framework concept. > > Namely, if repeaters and composites are an issue, then what I think would > be > the best behaviour is to take the id attribute on the markup and *in those > cases* apply a policy to avoid duplication. Such a policy should be more > meaningful than an autogenerated id from a counter, and maybe even > overridable. > > For example, if I have "foobar" on a repeater template, it will be nice to > generate "foobar_x" ids with "x" the containerID + iteration index. That's > a > useful Id that can be used to do javascript stuff. > > > > > igor.vaynberg wrote: > > > > in component frameworks it is very difficult to use ids because > > components are reused and composited, and managing all those ids by > > hand will be very tedious and you will still probably end up with > > duplicate ones in the produced html. > > > > -- > View this message in context: > http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15884377.html > Sent from the Wicket - Dev mailing list archive at > Nabble.com<http://nabble.com/> > . > >
