Sorry it took so long to respond, have a lot of things going on right now. Before I add my inlined responses I wanted to give an overview of what is going on. (in my current thinking)
ResponseBuilder is currently a sort of poor mans version of AOP. It allows me(you) to control exactly what happens before/during/after rendering of a component. It certainly isn't the only player involved, like the new ComponentRenderWorker hivemind chain that allows similar functionality to that previously provided by tacos javassist enhancements. (Only without the runtime compilation enhancements, and the additional flexibility of being able to add as many to the chain as you like without having to constantly duplicate javassist code.) The overall goal was to introduce a sort of middle man in the chain of component rendering. It's not exactly the purest/best implementation possible. Partly because of my inexperience in designing API logic, and probably partly because of some of the limitations of the existing design. (do I even need to mention T5 ?) The additional issue I had to design around was the concept of completely new OutputStream wrappers that have nothing to do with html markup, as in JSON responses. I wanted to try and provide familiar interfaces and flow of render, but also not hack and butcher IMarkupWriter into something it wasn't in this instance. So, I created a new interface that basically mimics (but hides, somewhat) the json.org javascript object interface. The largest nightmare I had trying to do certain portions of Tacos was in handling JavaScript contributed response content. (Ie PageRenderSupport / Body ) . These presented some of the trickier/peskier API's which I had been foaming at the mouth to refactor into a more publicly controllable API since day one. 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. The RepsonseBuilder.render(IMarkupWriter writer, IRender render, IRequestCycle cycle) method that you were questioning the existance of does precisely this. It's the foundation upon which all of this logic works. Aside from doing certain type checking of the writer passed in to account for the scenerio where people have created Nested/other writers, it also gets called by certain key parts of the framework. If you right click on the method in eclipse and do References - > Project you will see some familiar classes pop up: AbstractComponent.renderBody AbstractPage.renderPage BaseComponent.renderComponent Form.rewind These more or less represent the key inner-api areas in the majority of our inheritance tree "foundation"al logic. I could be totally off in my thinking, and very likely made some mistakes along the way so I'm not trying to be overly pedantic here, only doing my best to explain some of the thoughts going in in my mind when doing these things. Believe me, I'd love nothing better than to have someone be able to say: @MarkupRender public void renderComponent() or @JsonRender public void renderComponent() and be done with it, relying on AOP to guarantee my ResponseBuilder will be consulted on how to handle these methods without mucking around with inheritance. That would make things 10x simpler than what I had to go through to get to however confusing ResponseBuilder currently is :) On 8/4/06, Andreas Andreou <[EMAIL PROTECTED]> wrote:
So, ResponseBuilder is 'responsible for managing all content output that is sent to the client' and 'hands out IMarkupWriter instances to *render* components'. Additionally, it can also output content on its own, for instance to writeExternalScript, writeImageInitializations, e.t.c. In those cases, all ResponseBuilder implementations can either ignore those requests or use their own IMarkupWriter My problem is that in the second case, that IMarkupWriter may not be the correct one. This can happen when a component that surrounds Body (which actually calls writeExternalScript, writeImageInitializations, e.t.c.) renders its body to either a nested markup writer (perhaps to implement caching) , or to a completely new markup writer ( perhaps to render to file or email ) So, I simply feel that some ResponseBuilder implementations may have a use for an additional IMarkupWriter parameter in the writeExternalScript, writeImageInitializations, e.t.c. methods. And BTW, is there a reason why the IMarkupWriter parameter is needed in ResponseBuilder.render(IMarkupWriter writer, IRender render, IRequestCycle cycle) ??? --------------------------------------------------------------------- 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.
