Paul,
Thank you very much for your ideas. Very useful! I'm getting more
excited with every new client test I'm writing.
Regards,
Joost
On Thu, May 28, 2009 at 11:18 PM, Paul Field <paul.fi...@db.com> wrote:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
