I'm not even close to being done, but here is the start of that page. http://wiki.apache.org/jakarta-tapestry/41RenderCycleDesign
On 3/18/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Sounds fair. > > I will create a wiki page outlining what I've done so far, and ideally > where it would be nice to see everything go eventually. > > > On 3/18/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > I'm a little nervous here. > > > > Obviously, we're hitting limitations of Tapestry w.r.t. partial > > rendering. Tapestry harkens bake to an earlier, simpler time, when it > > was miraculous to render an entire page without an exception. > > > > I'd like to see more info, here or on the wiki, on the challeges here. > > What does it mean to partially render a page, especially in the > > context of PageRenderSupport (aka Body component, aka JavaScript > > support), and what exactly happens when that snippet of HTML (and > > JavaScript?) hits the client? > > > > On 3/18/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > > > > -- > > Howard M. Lewis Ship > > Independent J2EE / Open-Source Java Consultant > > Creator, Jakarta Tapestry > > Creator, Jakarta HiveMind > > > > Professional Tapestry training, mentoring, support > > and project work. http://howardlewisship.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 > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
