Ah sorry, you must have beat me to it by seconds! https://issues.apache.org/jira/browse/WICKET-1831
I'll close mine off as a dupe... With regards to scheduling, it would be really great to have this in 1.3.5 if it's not a big change. Thanks, Jan 2008/9/13 James Carman <[EMAIL PROTECTED]> > Done: > > https://issues.apache.org/jira/browse/WICKET-1830 > > If you don't mind, I'd like to take a stab at this. I can submit a > patch. Do you want me to develop it against trunk or the 1.3 branch? > I assume you want this to be optional in development mode so that we > don't screw up all of the generated markup matching test cases that > wicket (and other projects probably) have. > > > On Fri, Sep 12, 2008 at 6:04 PM, Igor Vaynberg <[EMAIL PROTECTED]> > wrote: > > open a jira issue and we can whip it up > > > > -igor > > > > On Fri, Sep 12, 2008 at 2:54 PM, James Carman > > <[EMAIL PROTECTED]> wrote: > >> That might be pretty cool! I can see how that might help constructing > >> your unit tests. > >> > >> On Fri, Sep 12, 2008 at 5:03 PM, Igor Vaynberg <[EMAIL PROTECTED]> > wrote: > >>> we can always make it so there is a setting that outputs the full path > >>> as an attribute of a component if that is helpful. > >>> > >>> eg > >>> > >>> <div wicket:path="some:path:to:this:div"> > >>> > >>> -igor > >>> > >>> On Fri, Sep 12, 2008 at 12:18 PM, German Morales > >>> <[EMAIL PROTECTED]> wrote: > >>>> 2008/9/12 Jan Stette <[EMAIL PROTECTED]> > >>>> > >>>>> Hi German, thanks for an interesting reply. > >>>>> > >>>>> Ruby probably wouldn't be appropriate in our environment, but it's > still > >>>>> interesting to see the principles involved in writing tests using it. > Some > >>>>> points I'm not clear about: > >>>>> > >>>>> When Wicket generates pages, as far as I can tell, the wicket:id > that's > >>>>> stated in the markup just shows the local wicket:id, not the full > path. So > >>>>> how can you refer to the item by the whole path, as in your example? > (Is > >>>>> there a way to change which ids are rendered in the markup?) > >>>> > >>>> > >>>> Yes, the wicket id is not usable to search the components, because > wicket > >>>> adds some extra characters in runtime. > >>>> > >>>> Normally, the "name" attribute should be good enough, and that's what > we are > >>>> using. > >>>> > >>>> From FormComponent#getInputName: > >>>> /** > >>>> * Gets the string to be used for the name attribute of the form > >>>> element. Generated > >>>> * using the path from the form to the component, excluding the > form > >>>> itself. ... > >>>> * ... > >>>> */ > >>>> > >>>> You should see attributes generated like: > >>>> panel1:panel2:form:panel3:innerForm:whateverElse:YourComponentID > >>>> > >>>> I'm also interested in what you say about using generated attributes. > One > >>>>> of the problems we're facing is that our application is highly > dynamic, the > >>>>> exact structure of a page depends on user configuration and setup. > So I > >>>>> was > >>>>> thinking about something like using AttributeModifiers to set known > ids on > >>>>> certain key components on a page. Is this what you mean by > "generated > >>>>> attributes"? > >>>> > >>>> > >>>> Yes, that's a possible way. Also i was mentioning it for components > that do > >>>> not have a name, like Links. > >>>> They are not FormComponents, but you still want to find them. > >>>> > >>>> > >>>>> Then, to make it all more interesting, there's Ajax. Our application > makes > >>>>> heavy use of Ajax, so components come and go on a page in response to > Ajax > >>>>> updates. I'm not sure which ids are available for identifying > components > >>>>> in > >>>>> this case. Looking at pages in FireBug, I can't see wicket:id tags > at all, > >>>>> but I'm not sure if that's missing something... Is this something > you have > >>>>> dealt with in your testing? > >>>> > >>>> > >>>>> > >>>>> Regards, > >>>>> Jan > >>>>> > >>>>> > >>>>> 2008/9/12 German Morales <[EMAIL PROTECTED]> > >>>>> > >>>>> > Hi Jan, > >>>>> > > >>>>> > We are using Watir, which lets you write tests in ruby. > >>>>> > > >>>>> > And we are using mainly wicket generated names for identification > of > >>>>> > components, but sometimes we use generated attributes too (for > example > >>>>> <a> > >>>>> > does not have name), or just the text in the html. > >>>>> > > >>>>> > Since the code is all in ruby, it is in theory easy to refactor in > case > >>>>> of > >>>>> > some changes. > >>>>> > For example, you can do this: > >>>>> > > >>>>> > textfield = ie.text_field(:name, > >>>>> "your:very:long:wicket:generated:name") > >>>>> > > >>>>> > or, in case of page changes... > >>>>> > > >>>>> > constant_defined_somewhere = "your:very:long:wicket" > >>>>> > textfield = ie.text_field(:name, constant_defined_somewhere + > >>>>> > ":generated:name") > >>>>> > > >>>>> > then you could fix all tests just changing the constant. > >>>>> > Well, this is an explanation of a quick solution to your particular > case > >>>>> of > >>>>> > changing the hierarchy. > >>>>> > But the idea is that you have a full (and good) programming > language to > >>>>> do > >>>>> > things "right": refactoring, reuse, and so on. > >>>>> > > >>>>> > Beware: > >>>>> > Watir does not always runs perfectly... the tests are somehow > dependent > >>>>> on > >>>>> > timing, which depends on the machine you run the tests, and other > >>>>> factors. > >>>>> > This is specially problematic in ajax calls. > >>>>> > That means that sometimes we get errors, then we run the same test > again > >>>>> > and > >>>>> > it works. > >>>>> > > >>>>> > Hope this helps, > >>>>> > > >>>>> > German > >>>>> > > >>>>> > 2008/9/12 Jan Stette <[EMAIL PROTECTED]> > >>>>> > > >>>>> > > This is a bit of a general question: I'd be interested in hearing > about > >>>>> > how > >>>>> > > people do automated tests of their Wicket applications. I'm > thinking > >>>>> > about > >>>>> > > system tests of the full application, not unit tests. > >>>>> > > > >>>>> > > There are of course tools like Selenium which let you automate > actions > >>>>> on > >>>>> > a > >>>>> > > web application. My colleagues with experience of this from > other > >>>>> > > applications tell me that one of the main challenges is to stop > test > >>>>> > cases > >>>>> > > from being very brittle by relying on the details of the > generated > >>>>> > markup. > >>>>> > > It would be nice if it was possible to target components on a > page in a > >>>>> > way > >>>>> > > that related them back to roughly the hierarchy of Wicket > components. > >>>>> Or > >>>>> > > even better, if individual parts of the page (links, input > fields, > >>>>> > buttons > >>>>> > > etc.) could be identified in a way that didn't break when there > were > >>>>> > > changes > >>>>> > > to the Wicket component hierarchy (say, new grouping components > being > >>>>> > > inserted higher up in the component tree). > >>>>> > > > >>>>> > > I realise this isn't the responsibility of Wicket, but are there > ways > >>>>> in > >>>>> > > which Wicket can help here, e.g. by generating ids or other > attributes > >>>>> > > inside the markup in a way that makes it easier to locate items > on a > >>>>> > page? > >>>>> > > Are there other tools than Selenium that people use, that makes > things > >>>>> > > easier? > >>>>> > > > >>>>> > > I'm looking forward to hearing about how other Wicket users deal > with > >>>>> > these > >>>>> > > issues! > >>>>> > > > >>>>> > > Regards, > >>>>> > > Jan > >>>>> > > > >>>>> > > >>>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> 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] > >> > >> > > > > --------------------------------------------------------------------- > > 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] > >
