This is for 4.1 only. On 3/18/06, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > > This sounds like a large change here. Are you thinking of putting this > in the 4.0 branch, or the 4.1 one? > > Why not release 4.0.x as it is and make this change in 4.1 - and then > release that one too? > > -- > Ing. Leonardo Quijano Vincenzi > DTQ Software > > > 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
