Questions are nice, people don't normally respond to things I post here very much :) Responses inlined.
On 3/28/06, Ryan Holmes <[EMAIL PROTECTED]> wrote: > > 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. I've been working with a couple of the dojo developers on pure dojo client side driven apps with minimal server layers, as well as consuming any and all information I can in regard to this area. I think that in most instances JSON responses are more efficient, depending on the type/amount of data being returned. If we want tapestry to be viewed as a killer ajax-supporting framework JSON is a must have. There are lots of nice articles being written about it. I highly reccomend at a minimum reading up on http://codinginparadise.org/weblog/ and http://alex.dojotoolkit.org . 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... Yeah, you have to have some way of determining the request type. It can really be any style you want, prototype adds request headers, dojo adds nothing, I 've used both methods..The response contributor infrastructure is capable of using any combination of the two to determine the request type and response to return. I did originally create an AjaxDirectService for tacos, but only because I didn't have access to Tapestry. I think building this into the ResponseRenderer instead of each individual service provides a much cleaner implementation, in that all of the tapestry services work with it by default, as well as potentially any services other people have written. It's possible that the actual ResponseRenderer interface will need to go eventually though, as it is kind of redundant at this point. 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. Ok, I think I answered this one above. 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 Not stupid questions at all, I'm glad someone is asking them :) To be really honest I may very well throw everything away that I've done so far if I don't like the way it "feels" once I really start fleshing out the component writing aspect of things. The next couple of weeks will probably see a lot of changes as I attempt to perfect and hone the whole render cycle using PropertySelection as my guinea pig. 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] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
