I was hunting around for this an hour ago after our HTML/JS/CSS guy
complained that I had broken everything. We have our own base classes so in
the constructor I've done:
Some(String id) {
super(id);
setMarkupId(id);
setOutputMarkupId(true);
}
So it will nuke the id set normally in the HTML so not really in the spirit
of Wicket. I can't decide if we should remove them (so just have <div
wicket:id="asd">) but that really not in the spirit of Wicket. Not great as
it is but want wicket and markup id the same anyway...
Nobody has complained for a few minutes...
Watter wrote:
>
>
> Eelco Hillenius wrote:
>>
>> On 6/25/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>>> I think reasonable behavior would be to generate markup id when
>>> invoked from constructor (instead of failing getting one from markup).
>>> However, I'm affraid the complications you have are caused by the fact
>>> the the component hasn't been rendered already, so it doesn't know
>>> it's markup position. At least we had similiar problems with 1.2,
>>> iirc.
>>
>> Yeah, I'm afraid of that too. And I understand that for some
>> components the markup position can only be known at runtime, right? Is
>> there any way anyone can think of how we could bind in an efficient
>> way before rendering?
>>
>
> I've read a number of threads on this subject and I'm still at something
> of a loss. I'm happy to accept that you guys are a 1000x better at
> framework building than I am and if you say that there are serious
> difficulties in implementing this, I can readily accept that.
>
> But what's the work around?
>
> There are at least two EXTREMELY common situations where as an application
> developer I need to be able to explicitly define an ID for an HTML
> element:
>
> 1) For CSS identification.
>
> 2) When I add javascript snippets to a page that interact with other
> elements.
>
> As it stands, I can't currently count on Wicket to leave my explicitly
> defined ID's alone. It's a little disconcerting to specify an ID in my
> template and have my rendered page not work as expected, only to find that
> when I look at the source in the browser, the ID has been dynamically
> modified.
>
> I guess I can learn to live with this behavior, but I'd love some advice
> on how to handle the use cases I mentioned above. Surely I'm not the only
> one running into those kinds of things.
>
>
>
--
View this message in context:
http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12524622
Sent from the Wicket - Dev mailing list archive at Nabble.com.
