Some random musings that might be of use...
My approach is that I will add additional HTML ids if it makes the
page/component more testable - i.e. the tests can drive the "need" for an
id.
However, that doesn't mean that every component needs an id. The reason I
particularly like XPath is using descendants; so my tests commonly use
xpath that looks like this: "id('some_root')//table" - the idea is that
I've added an id on a key element and then I use the descendant axis (//)
to track down the element I'm after. Descendants makes the test flexible
in the face of simple structural changes in the HTML. In other words, if
the structure changes from "<div id='some_root'><table>" to "<div
id='some_root'><div><table>" - the test still works.
A useful way of thinking about this can be to develop the HTML, tests and
XPath while being very mindful of how the end user thinks and the concepts
they use. If the user would say "I expect to see 1234 in the financials
table" then there's an important concept of "financials table" and it's
reasonable to have an id and use that directly: "<table
id="financialsTable">". If they say "I expect to see 1234 in the
financials table for IBM" then you might have ids for the companies and
classes for the tables, so the XPath might be:
"id('ibm')//tab...@class='financials']".
The user's concepts are much less likely to change than the page
structure, so I find this approach helps me to write less brittle tests; I
also find working like this has other benefits in readability, elegance of
code and helping the system to flex nicely when requirements change - but
that's another topic :-)
Hope that gives you some ideas.
Paul
------------------
Paul Field
Research IT
Deutsche Bank
"Joost Schouten (mailing lists)" <joost...@jsportal.com> wrote on
27/05/2009 23:22:12:
> Thanks for your response, and I kinda expected this might be a hard
> one to achieve. It seems harder than the reward it provides. Using
> xpath on html id's and or classes also does the job but is a bit iffy
> at times. Often my components don't need a DOM id, and I need to have
> my xpath know the markup of my component which would break once I
> change my markup. If I had the t:id available this would not be the
> case. So that is my "even better".
>
> The real power would come with having a DOM representation of the
> component instances and being able to assert my component/page holds
> the correct components (like wicket provides). but as far as I
> understand Tapestry made a clear decision not to use this paradigm,
> and I'm happy for it ;-)
>
> Thanks for your help,
> Joost
>
> PS: working on a temp job using wicket is quite nice btw. Finally get
> a chance to make a proper comparison myself in stead of going by the
> opinions of others. My conclusion: Wicket is a great tool, has some
> great testability features, very nice AJAX support and just like
> Tapestry, allows you to build complex applications fast. I'd still
> choose Tapestry for my own project though. I prefer the flatter way
> you can code you pages components in stead of having to match the DOM
> in your class and I find all the overriding of abstract methods and
> autonomous inner classes get quite messy. Most of all, in the cases
> where overriding default behavior is needed Tapestry rocks.
>
> Disclaimer: I know this is an unfair comparison since I have more
> experience in T5 than wicket.
>
> On Thu, May 28, 2009 at 12:36 AM, Paul Field <paul.fi...@db.com> wrote:
> > I believe this would be hard to add: the MarkupWriter has no knowledge
of
> > the components. So, to make this happen, each component would need to
> > write the appropriate "t:" attributes to the MarkupWriter as it
renders. I
> > suppose its conceivable to imagine intercepting the component render,
> > acquiring the attribute values and decorating the MarkupWriter to
output
> > them into the first element written by the component - but this seems
> > quite complex to attempt; there are probably lots of corner cases such
as
> > components that don't generate an element (and so have no suitable
place
> > in the output to write the attributes).
> >
> > I'm interested to know in what way this "would make life even better"
for
> > you... perhaps there is another way of approaching the problem. So
far,
> > I've written a lot of tests using PageTester and the tapestry-xpath
> > library and I'm just using HTML "id" attributes with a little XPath
and
> > it's working great.
> >
> > Paul
> >
> > ------------------
> > Paul Field
> > Research IT
> > Deutsche Bank
> >
> >
> >
> >
> > "Joost Schouten (mailing lists)" <joost...@jsportal.com>
> > 26/05/2009 22:23
> > Please respond to
> > "Tapestry users" <users@tapestry.apache.org>
> >
> >
> > To
> > Tapestry users <users@tapestry.apache.org>
> > cc
> >
> > Subject
> > Re: tapestry xpath and t: namespace
> >
> >
> >
> >
> >
> >
> > I guess I'm looking for a way to tell the MarkupWriter (or other
> > responsible DOM generators) to also output the t namespace in the
> > generated html. In particulair, I'm after having the t:id added. Would
> > this be hard to add, and what would be my entrypoint to start on a
> > patch.
> >
> > The idea comes from wicket which has a getTagByWicketId which I think
> > is quite powerful.
> >
> > Cheers,
> > Joost
> >
> >
> >
> > On Wed, May 27, 2009 at 12:22 AM, Thiago H. de Paula Figueiredo
> > <thiag...@gmail.com> wrote:
> >> On Mon, May 25, 2009 at 6:14 PM, Joost Schouten (mailing lists)
> >> <joost...@jsportal.com> wrote:
> >>> First off, I love the new xpath project. Unit testing components and
> >>> pages is a lot easier because of it.
> >>
> >> It can be used to write mixins too. :)
> >>
> >>> One thing that would make life even better is if I have a way to
tell
> >>> tapestry to print out all t: namespace params in the output xhtml
(for
> >>> testing purposes). Targeting specific components on a page will be
> >>> made a lot easier. Does such a setting exist?
> >>
> >> I guess it doesn't, as the DOM XPaths works on is the generated HTML
> >> output, not the template.
> >>
> >> --
> >> Thiago
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
> >
> >
> >
> > ---
> >
> > This e-mail may contain confidential and/or privileged
> information. If you are not the intended recipient (or have received
> this e-mail in error) please notify the sender immediately and
> delete this e-mail. Any unauthorized copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden.
> >
> > Please refer to http://www.db.com/en/content/eu_disclosures.htm
> for additional EU corporate and regulatory disclosures.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional
EU corporate and regulatory disclosures.
