Hmm....I guess I'm still not sure of the specific use case where this is needed, but I do remember thinking the javascript writing portions of the interface still felt dirty for some reason.
Go ahead and commit, if I see something I don't like I'll pipe up and post another message for discussion. (Sorry for questioning you, just want to make sure we're adding things in the most careful way possible. Ie I've found however long something took to do in tacos, it's always taken at least 2/3x longer to add it into Tapestry, but only because a lot more careful thought has to be put into it. ) On 8/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
From Jesse Kuhnert <[EMAIL PROTECTED]>: > To answer the question of why "not" allow people to pass IMarkupWriter's in > with certain methods and not others is because I believe I have properly > handled all scenerios for this logic already. Considering: <html jwcid="@Shell2 or even @Cache"> <body jwcid="@Body">...</body> </html> Shell2 or Cache wants to render all its body (which is @Body) in a buffer before appending it to the output - i believe this to be a reasonable requirement. So, they grab a nested writer, and call renderBody on it. But then DefaultResponseBuilder steps in and says: OK, write all to the nested writer, but i want JS + image initializations written to the initial writer (the one that produced the nested one), so .... ooops Is there a way to handle such a scenario? Well, there might be a way but i'm sure we generally should avoid such tricks + i'm sure you didn't have this in mind. -> Create another implementation of IMarkupWriter that monitors its nested child until it (the child) gets closed. While it's open, the parent writer forwards all its calls to its child. BTW, i just thought of this... So, we're now left to having DefaultResponseBuilder handing over our writer whenever a page contains our Shell or Cache component, or always... it is doable, but is it cleaner? Well, i don't think so - it's a workaround... Components shouldn't need to worry about their contents. Regarding ResponseBuilder.render, i meant to show that if it was missing the writer parameter, nested writers would also fail there. And BTW, PageRenderSupport isn't really PageRenderSupport... It is BodyRenderSupport. It would need to support methods related to <HEAD> to 100% justify its name. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
