It'll be a while before I can fully grok the update. Does PageRenderSupport fit in here? Can the concerns be split between the two and the final response synthesized from a custom PageRenderSupport and a custom IMarkupWriter?
On 3/19/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > I've updated the page with some javascript portions as well, the basic idea > that they encounter all the same solutions/problems that normal html content > does. Ie you need to be able to filter js content returns to the client, > which isn't currently possible. > > I don't think I'll have time to work on this anymore this weekend, but the > more I'm looking at my new classes the more it looks like they might need an > "aspectj" sort of solution to get them into the chain properly. Either that > or we go with javassist again. > > If I've left out any important parts in this document, or none of them make > sense at all please let me know and I will try to correct the text/examples. > > On 3/18/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > > > -- > 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]
