On Thu, Mar 6, 2008 at 1:33 PM, JP Saraceno
<[EMAIL PROTECTED]> wrote:
> 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.
wicket does not take ownership of id attributes by default, you have
to explicitly call setoutputmarkupid(true) on the component.
> 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.
i do understand that. however, html ids were created using thinking
that the entire html document is generated by a monolithic generator.
when you use a component oriented framework as a generator for html
something that is unique across the entire document becomes difficult
because each component works in isolation - that is where the power of
these component oriented frameworks comes from.
so if i write a panel that has this markup:
<wicket:panel>
<div wicket:id="foo" id="bar">content</div>
<a href="#" onclick="document.getElementById("foo").hide();"/>
</wicket:panel>
it all works great. now what happens when i put two of these panels
into my component hierarchy?
or maybe i use two third party components that happen to use the same
hardcoded markup id?
usecases for calling setoutputmarkupid(true) have to do with you
having to attach some dynamic client-side behavior to these
components, so taking over the id - which is the only way to uniquely
identify a node in html seems reasonable to me. you cant have cake and
eat it too.
> CSS id selectors are very different than class ones, both conceptually and
> in practice (i.e. the way browsers handle it).
yes, and this is suggested as a workaround, not as a better alternative.
> 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.
we have never recommended relying on id attributes once you call
setoutputmarkupid(true), in fact we have recommended against this all
along.
> The change on this policy seems derived from an implementation issue rather
> than a framework concept.
not true, see above. and i am not aware of any change in
policy...wicket still doesnt touch anything by default
> 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.
yeah, sounds great on paper...would you mind coming up with a patch?
and if you try, dont forget that one of the most common usecases that
gets our users to complain and that we have recently fixed is this:
TextField tf=new TextField("foo");
add(tf);
tf.setOutputMarkupId(true);
String id=tf.getMarkupId(); // <== this has to return what will be in the markup
add(new SomeJavascriptBehavior(id));
-igor
>
>
> 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.
>
>
ist
