go for it if you want, its a 5 minute thing anyways. and yes, there should be a setting that is off by default in both dev and prod modes.
-igor On Fri, Sep 12, 2008 at 4:04 PM, James Carman <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
