On Thu, Oct 15, 2009 at 1:14 PM, Per Lundholm <[email protected]> wrote: > Looks like a patch to make it easier to use Selenium to test your > webapplication. > > Selenium is very fond of id in tags. >
Correct, this patch (PD) we use in order to get Selenium to work, and it works pretty well. What is basically the case is that Wicket uses a single global counter which ever increases to generate IDs. Because hierarchy can change, components are added this ID is not bound to the wicket component, leaving to a new ID the next time round. What this patch does is to tie the generated ID to the wicket component, but that's not the whole story because if anything is different in your hierarchy the paths will still change. It will work for selenium if you do everything exactly the same, but that's hard to maintain/ What you need is that when generating a ID, the ID is generated with the knowledge of the component, such that you can generate the ID based on the domain knowledge of your component. The crux is that the wicket method in the Session to generate an ID had no parameters, while if it would get the component requesting the ID, then an subclasses wicket Session instance can incorporate this knowlege. Basically the patch is just adding the parameter to that wicket method and the other 80% of the code is just making sure everything is backward compatible. How can one use this subclassing, well, for instance you have some kind of listing component on your page that enumerates items in your database. Because the content of the database changes, the hierarchy will change, rendering IDs useless. Now you could resolve this by letting the component that lists a single item explicitly set the markup ID, but if this itself is a Panel containing subitems, then you need to set the IDs of all those subitems too. That becomes nasty bit of either passing arguments or traversing the tree. However, with the patch you can put this logic in the session. When an ID needs to be generated, use the ancestor tree of the component for which the ID is needed up to a stable ID component (the one which knows which database element, and then instead of using a global counter, use a counter in that component. This was the ID has become stable, and most of the logic is where is belongs, the Session instance generating IDs. Maybe not the nicest example, because a lot of knowledge is infused in your Session class, but there are better cases available (we have a plugin system for wicket, where we can use a quite generic mechanism). It's illustrative though I hope. \Berry --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
