Sounds like reasonable desires to me. So you think enabling this on PartialFor is ok as long as it's clearly documented that it will only work with PartialFor and no other kind of loop?
I agree with the just working part. Anything in documentation saying it will work under this condition only if blah blah should probably be a red flag for anyone. :) This really will be addressed I promise. Thankfully I think we are just about there. Not too many more days until monday :) In the interim though I will add it to tacos to generate ideas and get a better feel for it. Help is always welcome :) I wish the forrest xdocs were wiki-isable. Does it sound silly to think that they should just be moved to the wiki instead? The major problem that presents is that the wiki isn't an obvious place to go so it becomes another problem. Let me know I guess. I'm not sure how much to say/offer, but I feel very comforatable doing things with you with code/otherwise so changes can be made.. jesse On 11/22/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > Jesse Kuhnert wrote: > > 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? > > > Yes, it sounds good / reasonable. I know it's better to focus, but then, > 2 "principles" to apply, IMO are (for this and everything we do in > programming): > > 1) It should "just work". If there's a special limitation due to lack of > time, then it should be clearly documented (not "it may work" but "it > will work on this, and on this it won't"). It's much preferred if the > component itself checks this and throws an exception. > > 2) It should be documented. It's like a marketing effort for developers, > hehe. > > Of course, in any case I'd be glad to help. But as a general approach, > it sounds good... > > -- > 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]
