I think this <MONH> which has now been named "ResponseBuilder" still wouldn't directly handle the actual IMarkupWriter sort of logic, but takes the pipeline of control away from AbstractComponent/AbstractPage and out into some classes that are a little more flexible in being overriden as well as knowledgeable about other important things, like the response type to hand out.
Don't get me wrong, this is a really big change in interfaces. The basic idea is that we've got a number of things going on in renderComponent() for any given set of components that I would like to break up a bit more. So really, the renderComponent() methods won't go away, just the process of how/when those methods are called. I'm just moving a little logic around is all. Initially I think this will only affect the Body/RenderBody/For components overly much. It is still hard for me to describe clearly right now as I am literally in the middle of implementing it, but I'll come back with something better in a little while. I'm on the right track though I think . So...Ideally I would like IComponent.renderComponent() calls to mostly only deal with actually writing their markup, not rendering child components or looping over things. The same goes for the rewind cycle. No more validating AND parsing of incoming data in one step (don't know how to do this efficiently yet) . It's almost done now though so a clearer explanation should be had shortly. jesse On 3/18/06, Fernando Padilla <[EMAIL PROTECTED]> wrote: > > So I'm a little confused. > > "the actual rendering wouldn't happen directly in this method though, > instead the <MONH> (short for mysterious object name here) would be" > > how does that work for our custom components? the MONH wouldn't know > how to render our custom built components... > > Jesse Kuhnert wrote: > > I've been pulling my hair out all day, silently cursing the blank walls > > around my office but I can't seem to find an elegant solution to manage > the > > rendering cycle with this new logic any other way. > > > > The basic problem is that for JSON or Ajax responses I'm going to need a > > different MarkupWriter implementation. If it was Ajax only then there > > wouldn't be as much of a problem, I could extend IMarkupWriter a little > bit > > and call it a day, not worrying about changing method signatures and > > such....The JSONWriter is an entirely different animal though, so is the > > logic that handles rendering ajax requests. The method signatures of all > > these render calls would have to be duplicated in order to handle the > JSON > > responses...And we all know duplicating logic will only lead to more > bugs > > and headaches later on. > > > > So...To kill a few birds with one stone I'd like to introduce an interim > > solution somewhat based on what Howard has already mentioned. I don't > know > > what to call the object yet but it would "contain" the right kind of > > MarkupWriter depending on the request type. It would also contain all of > the > > logic that handles determining whether a component should actually > render a > > response, and if so, what type of response. > > > > So...The old method signature of renderComponent(IMarkupWriter, > > IRequestCycle) would more or less go away. I don't mean to actually make > it > > go away right now, but will instead duplicate logic just this once to > allow > > backwards compatiblity. > > > > The new interface would be something along the lines of > > renderPipeline(<Myseterious Object Name Here>, IRequestCycle); > > > > The render implementation would then do the normal sort of housework > that it > > always does, for instance the For component would setup it's collection > and > > iteration loop, the actual rendering wouldn't happen directly in this > method > > though, instead the <MONH> (short for mysterious object name here) would > be > > called with a signature somewhat like: > > > > <MONH>.renderComponent(IComponent component, IRequestCycle cycle); > > > > The logic for determining JSON vs normal vs Ajax writers and which > methods > > to call on the component would be encapsulated by this new object. This > also > > brings us closer to providing a more centralized/seperate sort of logic > area > > for transitioning the state and rendering of these objects out of the > hands > > of the objects themselves and into something a little bit more > managable. > > > > I'm sure Howard's ideas will ultimately create a much better solution > for > > this, but without completely duplicating and hacking up the current > design > > internals of tapestry I don't know a better solution. > > > > Stop me now before I get too far I guess... > > > > -- > > 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
