i think matej explained it very well in the link you gave in your mail. The markup id of a component is only know when the component is rendered in wicket we have 2 phases:
1> request phase (listener phase/component construction phase) 2> response phase (the render phase) so if you want a markupid in the first phase OR you want a markupid of a component in the second phase that is itself not rendered yet. We have to generate it because the markup is not attached to the component yet and we don't know the markupid from the html Also if we get the markup id from the template then we could generate wrong/invalid html because if you would use that in a repeater you have 2'or more of the same id. So why do you need the id? Let the id be generated and use only class for css The only problem is custom javascript. But can't you also parse that javascript also through wicket? and replace the ids at that time? johan On 10/22/07, Watter <[EMAIL PROTECTED]> wrote: > > > > > igor.vaynberg wrote: > > > > i am not aware of any "show-stopping" bugs, so i am ok if the next > > release is an RC1. > > > > I'll pipe in as a user here. We have struggled with the markup ID issues > discussed here: > > http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12525507 > > If this can't be handled in an intuitive manner (i.e. utilizing the ID > specified in the HTML template) then at the very least, this behavior and > any workarounds (like the one at > > http://www.nabble.com/Re%3A-getMarkupId-doesn%27t-return-the-id-from-the-markup-p12532067.html > ) > need to be well documented. > > I realize that the way this works may be second nature to you as > developers > of the framework, but you have to understand that from a user's point of > view it's a complete surprise that we can't reliably specify ID's on our > HTML elements. I still don't completely understand the technical reasons > for > this, but I do trust that if it were easy to fix, it would have already > been > done. I just need to have a clearly defined set of processes that I can > point my manager and development team to when they encounter this issue. > If > I fully understood the problem and the solutions, I'd create that > documentation myself, but unfortunately, I don't. Even Matej's workaround > that I linked to above doesn't make complete sense to me. I think I > understand the general goal, but not technically how to achieve it. > -- > View this message in context: > http://www.nabble.com/beta-5-this-weekend--tf4657032.html#a13349276 > Sent from the Wicket - Dev mailing list archive at Nabble.com. > >
