Hehe....Yes calling the render methods is still not ideally efficient... It is still easy to test a component/page..Or at least "fairly" easy. Under org.apache.tapestry.test.util (I think) there is a Creator class that will let you create an instance of a component/page with properties (even of your abstract methods) setup via a map or array parameter.
You could then pass in a mock request cycle, with a NestedMarkupWriter instance, which will allow you to capture the string data written to it's internal buffer and then assert whatever you want to assert with that data. I plan on adding some documentation on this as well :) The service idea is a possible workaround, but depending on how speedy all of these things get expedited I really do want to attack the direct update + component identity problems as the first order of business, if at all possible. It does affect me as well :) In the interim though, there is enough infrastructure available in tacos alone that I can make PartialFor work with things they way that we want. I didn't want to do it before because it would be another one of those "you can use it - but.." scenerios, but it would be a good chance to play with stuff in a smaller-impact environment anyways. Does this sound good/reasonable? On 11/22/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > Jesse Kuhnert wrote: > > You are mostly understanding correctly, besides the listener reloading > > the entire page in the response, sort of... :) > > > Yes but no... The listener isn't reloading the entire page, but it is > indeed *rendering* the whole page. Am I right? > Two points: > > 1) Direct component refresh is not reliable. That's until the "use with > care" warning is removed, hehe... Now if we have a Direct refresh that > 'just works' (I can put it in a @For or anywhere and it would work) > that'd be great. But the "component service" solution is also useful. > > 2) I'm thinking of in-container component testing. I'd call the > "component direct" service, or whatever is called, and use some HTML > testing tool to check my components. Now, components really *shouldn't* > have any external dependencies besides the ones define in its interface > (the JWC file, annotations, etc), right? Or I could try to manually test > a component by calling it directly and setting the parameters on some > kind of component-test web interface. > > If the component update is rendering the whole page, isn't this process > expensive? Even if it's cached... > (and if it's not cached, the devoleper time is also valuable.. you know) > > -- > Ing. Leonardo Quijano Vincenzi > Director Técnico > DTQ Software > > > > --------------------------------------------------------------------- > 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]
