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.
