I don't think a custom IMarkupWriter will cut it in this case (except for the JSON calls).
The PageRenderSupport object I haven't event thought about, other than knowing that I'll have to add ~something~ into the chain of method calls that allows filtering what goes into pagerendersupport and what doesn't. I also haven't studied closely enough what the interactions are between it and the Script component, which I'm sure are many. Eithery way I'm guessing it's going to be the same general idea as the IMarkupWriter issue. Refactoring some things to allow filtering, while also adding in additional logic to handle the new logic involved in managing the client side state as well as server side. For instance, it's very likely that a lot of components in the system will have a corresponding dojo "widget" driving their interactions in the browser. In these scenerios it is very undesirable to simply re-render the html. Most likely many of the script interactions will involve calling a method here and there on the widget, or returning JSON structures so that the widget can update it's data model. For the render cycle, I think I'm back to a saner position...One where I've come to terms with the fact that I can't just use these new objects and magically breakup the whole renderComponent chain. It will have to either be the way that tacos does it now, via subclassing components and intercepting the renderComponent call with javassist, or the newer sexier method of using something like aspectj so that our render enhancements don't have to exist inside manually printed StringBuffer statements, but can live as real live java classes capable of being run against unit tests. Those are my thoughts so far at least. I won't be able to work on much of anything again until this weekend as I have a release deadline of Friday for a client, but I'm hoping to make some real headway this weekend. If AspectJ has been studied by someone else already and sounds too new / unreasonable for some reason it would be nice if someone would save me the time of trying to figure it out. Otherwise I can try and go with ye old javassist. (If people agree with the designs laid out so far) jesse On 3/20/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > 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] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
