Unfortunately, the fix for http://issues.apache.org/jira/browse/WICKET-694 had some side effects I didn't come across when testing :(
It's a bloody shame, but it seems that already too much code assumes it can call getMarkupId where it shouldn't. I'm leaving the bug open, but at this time I have no idea on how to fix it. Eelco On 6/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> I believe the current behavior is intentional. Igor seemed to feel > quite strongly about not using markup id specified in template. The > reason is that it's not unique and it behaves wrongly in repeaters or > when you put the component to page twice. I remember having this discussion a very long time ago, but I though we decided that even though there is some danger in it, it is the responsibility of the user. Which is the right thing imo. > I'd actually prefer wicket to preserve specified attribute because it > can be handy in cauple of cases. But that's just my opinion. The thing is that we call this method getMarkupId, but it only returns the id you can find in the markup when you *don't* provide one explicitly (and tell the component to write it's id). Even if you set setOutputMarkupId(true), Wicket won't override the id in the markup, which of course has the effect that any Javascript refering to the id - like the datepicker does - does not work. So we currently have the situation that if you set the id explictly, stuff won't work anyway, and we have a method name that doesn't do what the name hints (for it's current behavior it should be called something like getGeneratedMarkupId). Eelco
