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
