I have a few questions I meant to bring up when you first put up the
41RenderCycleDesign page:
1.) How important is it that Tapestry support JSON responses? I mean,
what are the benefits of JSON over XML besides performance? Does it
actually give us functionality we wouldn't otherwise have? OK, that was
three questions but you get the idea. The reason I bring it up is
because it seems like IMarkupWriter is pretty deeply ingrained in
Tapestry and that a number of issues would go away or at least be
simplified if we didn't support JSON.
2.) You've referred to using "request meta information" to determine
what type of response that should be given. Do you mean client headers
or what? Why not have an explicit AjaxService to handle AJAX requests? I
mean, don't AJAX components "know" that they're sending AJAX requests?
Woops, guilty again of packing a bunch of questions into one...
3.) It looks like the primary reason for having a ResponseBuilder is to
provide writers that aren't IMarkupWriters. If it wasn't for that issue,
couldn't you use configurable ResponseRenderers to do what the
ResponseBuilder is doing? iow, modify ResponseRendererImpl or add new
ResponseRenderer(s) instead of creating an identical (i.e. redundant)
interface.
Hope these aren't stupid questions as I know you've spent a lot of time
on these issues and I haven't. BTW, nice job on the 41RenderCycleDesign
page -- I'm surprised it hasn't elicited more comment.
-Ryan
Jesse Kuhnert wrote:
I would like to preface this with saying that as far as I'm concerned this
is only the result of various ideas howard's casually been floating around
on the list. Maybe I've inferred and done it slightly differently than he
originally meant, but I'm also hoping he'll jump in and help me describe wtf
I'm trying to say in case it's not clear.
What I need is a way to genericize the interface that requires passing in
IMarkupWriter/IRequestCycle at certain points.
Luckily for us if we float up the interface chain the IRender interface
semantics were left somewhat closed up to the general public. Though I can
see a fair amount of references using it internally to tapestry I'm hoping
that the public at large has stuck to IComponent.renderComponent() to do
most of their logic. (fingers crossed)
What I want to do isn't overly complicated. I want to make IRender a little
bit more private and internal to tapestry, and expose a new/different
interface. I ~can~ get what I want if I were to change IRender to look more
like this:
public interface IRender
{
/**
* The principal rendering/rewinding method. This will cause
* the receiving component to render its top level elements (HTML
* text and components).
*
* <p>Renderring and rewinding are the exact same process. The
* same code that renders must be able to restore state by going
* through the exact same operations (even though the output is
* discarded).
*
**/
void render(ResponseBuilder builder, IRequestCycle cycle);
}
This is still more or less the same thing, only ResponseBuilder contains the
IMarkupWriter instance. It will of course pass IMarkupWriter (or another
writer instance for other things, if relevant) into the right components at
the right places. (still calling renderComponent(), as per normal )
So now, instead of calling IRender.render(), you call it with a
ResponseBuilder, and he sort of takes over from there. This is what I need
in order to support multiple Markup type interfaces/ajax/json without
breaking backwards compatibility. Here is what the ResponseBuilder interface
currently looks like:
/**
* Renders the response to a client. Handles transitioning logic
* for setting up page and associated components for response.
*
* @param cycle
* The main request cycle object for this request.
*/
void renderResponse(IRequestCycle cycle);
I'm hoping if the changes being proposed are ok'd a new method will be added
into the chain:
void render(IRender render, IRequestCycle cycle);
I think you can see where I'm going with this quite clearly with the method
above added in.
Everything is in place for me to do it, but I really want to make sure this
is ok before I move forward as it's quite a large change.
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
