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#a12524564 Sent from the Wicket - Dev mailing list archive at Nabble.com.
