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
