>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]
