Not quite true. What I've done is the past is record my tests w/ the IDE then export to Java. Once you've got the JUnit generated for you it's not too hard to take a quick pass and convert all of the ID lookups to XPath lookups. If you know for sure when writing the test that the ID really is unique and looks something like 'myWicketIda' then you can go with something simple like "//*[starts-with(@id, 'myWicketId')]" (forgive possible syntax error its been a while). If the ID isn't unique or you just want to be safe for the future then construct a unique path with your XPath expression.
----- Original Message ----- From: Pierre Goupil [mailto:[email protected]] To: [email protected] Sent: Tue, 13 Apr 2010 07:14:47 -0400 Subject: Re: How to get stable DOM IDs without hacks? > Craig is absolutely right, of course, but if you want to be aware of what an > id value is and OK to manage its uniqueness, setMarkupId() still applies. A > use case for this is, for instance, a Selenium test: Selenium locates the > HTML elements by ids and you have to know them at page-write time in order > to be able to provide them to it. > > Regards, > > Pierre > > > On Tue, Apr 13, 2010 at 6:04 AM, <[email protected]> wrote: > > > Thanks a lot to you both for your solutions! > > > > Regards > > > > Bernard > > > > On Mon, 12 Apr 2010 23:36:16 -0400, you wrote: > > > > >Like Pierre said, component.setMarkupId(component.getId()) will work, but > > it was discussed just a couple of weeks ago why that's a bad approach. > The > > thread isn't appearing on nabble though, not sure why that is. Anyway, a > > safer approach (to prevent duplicate ID issues) is to generate your > > javascript calls at the server using the markup ID as a parameter. It > > sounds like you have a function like > > > > > >function func() { > > > var elem = document.getElementById("someId"); > > > // do stuff to the element > > >} > > > > > >so just modify to > > > > > >function func(id) { > > > var elem = document.getElementById(id); > > > // do stuff to the element > > >} > > > > > >and output a call to that function using something like a > > StringHeaderContributor or implement IHeaderContributor if you need to > call > > at page load or use AjaxRequestTarget if in an ajax request. > > > > > >----- Original Message ----- > > >From: Pierre Goupil > > >[mailto:[email protected]] > > >To: [email protected] > > >Sent: Mon, 12 > > >Apr 2010 18:36:55 -0400 > > >Subject: Re: How to get stable DOM IDs without > > >hacks? > > > > > > > > >> Hello, > > >> > > >> You can use myComponent.setMarkupId("blah"), but then it's up to you to > > >> ensure the id uniqueness. > > >> > > >> Regards, > > >> > > >> Pierre > > >> > > >> > > >> On Tue, Apr 13, 2010 at 12:35 AM, <[email protected]> wrote: > > >> > > >> > Hi, > > >> > > > >> > Wicket has its own mind - it changes IDs in HTML forms so JavaScript > > >> > breaks. > > >> > > > >> > Example: > > >> > > > >> > Source: > > >> > <input type="button" wicket:id="addButton" id="addButton" > > >> > value="Add"/> > > >> > > > >> > Generated: > > >> > <input type="button" id="addButtona" value="Add" name="addButton"/> > > >> > > > >> > Please note that Wicket renames the id from "addButton" to > > >> > "addButtona" while it does not change the name attribute value. > > >> > > > >> > So we would have to create a Button subclass and: > > >> > > > >> > @Override > > >> > public String getMarkupId(){ > > >> > // As an example, use the wicket:id value ... > > >> > return getId(); > > >> > } > > >> > > > >> > and in HTML, we have to write a warning as a reminder of this hack: > > >> > <!-- Wicket overrides id from wicket:id value --> > > >> > > > >> > This is a maintenance problem and a performance problem because the > > >> > additinal classes cost memory and CPU. > > >> > > > >> > Any ideas? > > >> > > > >> > Thanks, > > >> > > > >> > Bernard > > >> > > > >> > > > >> > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: [email protected] > > >> > For additional commands, e-mail: [email protected] > > >> > > > >> > > > >> > > >> > > >> -- > > >> Les deux règles universelles du bide : > > >> > > >> 1) on n'explique pas un bide > > >> > > >> 2) dans le futur, un bide sera toujours un bide. > > >> > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [email protected] > > >For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Les deux règles universelles du bide : > > 1) on n'explique pas un bide > > 2) dans le futur, un bide sera toujours un bide. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
