If someone could read and respond to this page I'd be very appreciative. http://wiki.apache.org/jakarta-tapestry/41RenderCycleDesign
There are still a few mirky points I haven't quite figured out, and didn't think I'd be able to realize fully until I started implementing the logic inside of a few components to see how it feels and which parts don't make sense. Of course to even get to the point of being able to "try out" some of these designs there is an awful lot of infrastructure that has to be put in place, which is why I started this thread. j On 3/18/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > 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 > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
