Have you thought about using a specialized class value for links & etc. that are going to be involved in the test suite, and then selecting by class instead of id?
Just an idea ... On 3/23/07, Doug Hauge <[EMAIL PROTECTED]> wrote:
Thanks for the response. We are in the process of migrating our application to Tapestry, and in the process making it more easily customizable and testable. The solution we are looking for seems to be a reasonable way to satisfy the following constraints: 1) Within a component, identifiers given to sub-components should be as simple as possible while being descriptive. For most components, little thought should be required about what other components might appear in the page. 2) Within a page, components should be able to be rearranged, added, and removed without affecting the identifier given to the associated element(s) in the rendered HTML. Such an immutable identifier is useful for Selenium tests that are valid across such page modifications. 3) In keeping with the DRY principle, we would like to avoid requiring a mixin or other boilerplate code to be included in all our components in order to construct unique identifiers. The problem is that (1) can easily lead to a case where multiple components specify the same component id for their children, because the component writer has no knowledge of what other components may be placed in the page, and in order to keep the component id simple we don't want to require the component writer to always apply a prefix to increase the likelihood of uniqueness. All that we want to require of the component writer is that within the component, all the identifiers are unique. There might also be cases where the same component is included multiple times within a page, either directly or indirectly. Note that an ideal solution for us would also allow us to similarly transform id attributes on HTML elements in the template. If we can't, we either have to avoid specifying identifiers on raw HTML elements or to make sure that all components that may ever be placed on a page choose identifiers that are unique among those components. We have a temporary solution now that uses a mixin that traverses the DOM and adjusts identifiers in its 'afterRender' method, but this violates (3) and is a bit of a kludge. Thanks, Doug > -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Friday, March 23, 2007 3:56 PM > To: Tapestry users > Subject: Re: T5: Customizing generation of client id from component id > > I'm afraid that's a use case that wasn't foremost in my mind when > coding this stuff up for T5. Still, if you explicitly set component > ids, it's highly unlikely that they'll change dramatically from one > build to the next ... could you elaborate on the situation that drove > you towards this kind of solution? > > On 3/23/07, Doug Hauge <[EMAIL PROTECTED]> wrote: > > Is there a way to customize the generation of a unique client id from a > > component id? We would like to generate the unique id in such a way that > > it would not change across most modifications to a page, mainly so > > Selenium tests can be written that will work across page redesign. The > > current method of appending a suffix to a component id does not seem to > > allow this, so we would like to be able to generate a unique id by > > prepending the component ids of ancestral components. We could > > potentially implement our own PageRenderSupport service, but the > > 'allocateClientId' method only takes a string parameter, so we don't > > have the context we would need (in particular, the ComponentResources of > > the component for which we are generating the id). > > > > > > > > Thanks, > > > > Doug > > > > > > > > > > > > > > > -- > Howard M. Lewis Ship > TWD Consulting, Inc. > Independent J2EE / Open-Source Java Consultant > Creator and PMC Chair, Apache Tapestry > Creator, Apache HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > 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]
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
