my recommendation has always been to let wicket generate the ids. the css argument is invalid imho because you can just as easily use a class instead of id
the javascript does carry some weight. if the javascript is inlined/static and in the page then yeah, it sucks that wicket would change the attribute, that is why we have a setmarkupid() that lets you override it. if you use it it is then up to you to make sure the id you set is unique. personally i keep my js snippets in .js files and use texttemplate with variable replacement to stick them into head. that way all my needed ids are just variables whose value i collect before outputting the javascript. -igor On 9/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > the wicketid doesn't have to be unique only if you are setting that id > right > into the markupid yourself. > if not then wicket makes them unique (if we didn't do that THEN wicket ids > should be unique) > > The 2.0 way we just can't do because we don't know it early enough now > only > in onBeforeRender > igor did try some things out i believe > > But what would be nice if we try to get it from the html. But if you call > it > in your code to soon then we generate one. > But even if we take it from the html then still if the component is reused > we have a problem because it is not unique > > johan > > > On 9/6/07, Sam Hough <[EMAIL PROTECTED]> wrote: > > > > > > Guess the worst thing is that Wicket ids now have to be unique within > the > > whole page not just the parent component... > > > > The behaviour they had in 2.0 does seem better. > > -- > > View this message in context: > > > http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12525262 > > Sent from the Wicket - Dev mailing list archive at Nabble.com. > > > > >
