Yes I'll be looking into the Avatar PPR solution as well, I'ver heard that they have some pretty good ideas. I also like the Idea of a onPartialRefresh javascript attribute (although it seems indeed a bit early :-)
Regarding the question of AA dependencies, I'm not planning to use this permanently, just to start with something for playing around with new components that support attributes like partialTriggers, or listener-components without having actually to implement the client-side JS first. To make it clear I'm not suggesting to add an AA dep in sandbox, we will want to have our own client-side code don't we :-) On 6/16/06, Rogers Reilly <[EMAIL PROTECTED]> wrote:
I'm not a contributor, but that approach sounds perfect to me. I've used PPR for a couple of projects now, and swapping out the iFrame client-side for dojo.bind would be a great improvement. Would give you async, for one; and obviously does away with custom JS. Another nice feature (I know it's early for requests :-) ) would be to allow an "onPartialRefresh" javascript attribute to any component that triggers PPR. From time to time, I find myself with a rather lengthy PPR request, and would like to do something on the client to indicate more content is loading (beyond the native browser "I'm loading" behavior), and then undo that something when the new PPR content shows up. The first part I can do with an "onClick" handler on the control (although an explicit "onPartialRequest" would be better), but the second part I can't, because the custom JS that displays the page isn't exposed. I'm figuring by the time I get around to digging into the existing Trinidad JS and exposing it myself (which, I'm sorry to say, falls somewhere below watching World Cup on TV on my to-do list), you might be done. :-) Also, on the subject of PPR, what is the scoop on Avatar? They seemed to have a PPR solution pegged pretty well in the JavaOne demo, and being cooked into JSF itself, it would seem like the preferred route--at least on the server side. I know Adam was part of that presentation ... is that stuff just too far off to be worth counting on for Trinidad PPR under JSF 1.2? -Rogers Ernst Fastl wrote: > Thanks for your ideas guys, and yes overworking the existing PPR in > Trinidad > to make the Client-Side-Code to use XMLHttp sounds good to me. The thing > is my Proposal for Google ist titled: > > "Implement AJAX Partial Page Rendering Support in Apache MyFaces" > > > > Since, if I understood it correctly, trinidad is now part of MyFaces > it should > be ok to work on that Code. But my original Idea was to compare the > Approaches of trinidad and AJAX Anywhere to find a solution for > MyFaces which combines advantages from Both. > > The AJAX-Anywhere based component in the sandbox ( not intended to be > commited > to MyFaces in this version) Is just to start "playing around" with PPR > in the tomahawk > library. > > I don't know if and when the component libraries of trinidad and > tomahawk are to be > merged, but I could think of implementing PPR in tomahawk reusing much of > the trinidad Server Side PPR Code and Reimplementing the Client Side Code > based on the existing AJAX Infrastructure in MyFaces (which I think > is using the DoJo-Library). Once this is finished this Client-Side > code may be > used to on the other side enhance the trinidad Client-Side Code. So in > the > end both Component libraries would benefit from each other. > > thoughts? > On 6/15/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > >> Ernst, >> >> trying to get rid of all the custom JavaScript sounds very good. Don't >> like that too! >> >> Is the suggestion from Adam valuable for you? >> I think it should be better to *enhance* Trinidad's PPR instead of >> "creating" new PPR style components for the sandbox. Also not having a >> AA dependency sounds great, to me. >> >> I think enhancing an existing solution, or providing a new >> "architecture" should be fine with the SoC rules, right? >> >> -Matthias >> >> On 6/15/06, Ernst Fastl <[EMAIL PROTECTED]> wrote: >> > Hi There! >> > >> > In the PPR-Implemetation I would rather like to avoid those iframes >> > and do it completly >> > with AJAX. The Client-Side Implementation of AJAY Anywhere seems >> > pretty much straight >> > forward to me. When using it together with MyFaces it works the >> following way: >> > >> > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF >> > id="x">-Component >> > those get rendered as <span>-tags with id="aazone.x" >> > >> > 2.) Define which zones are to be reloaded with AJAX-Calls by defining >> > a JS-Function: >> > getZonesToReload(url, submitButton) >> > >> > 3.) Substitute the submit-function of the main-Form to use >> submitAJAX instead >> > >> > 4.) if a button is pressed or a value changed that would lead to a >> > submit of the mainForm, submitAJAX checks based on getZonesToReload if >> > an AJAXRequest is to be done. >> > if not the form is submitted as usual. >> > >> > 5.)If it is an AJAX request a post-request is build with all >> > parameter/value pairs of the form >> > elements + >> > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its >> > an AJAX-Request >> > -aazones=id1,id2 - Tell which zones need to be updated >> > >> > 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses >> > the HTML in the Response to extract the specified zones (big >> > disadvantage the whole component >> > tree gets rendered internally). >> > >> > 7.)HTML-Code of the zones is packed into xml-tags with the name of the >> > zones as attribute and send back to the client >> > >> > 8.)Client parses the response and sets element.innerHTML of the >> > zone-span-elements with the contents from the response >> > >> > What I like in this approach is the Javascript-Code that generates the >> > Post-Request and the Code that parses the >> > response and updates the DOM. >> > >> > The Server Side is pretty ugly. I would prefer to find a way to invoke >> > only the affected components which I think >> > should also make it faster. I haven't yet completly understood how >> > trinidad handles this, but I think they have >> > the cleaner solution for the server-side. >> > >> > What I also don't like is the JS-Code you have to write in your JSPs >> > (calling substitueSubmitFunction, defining getZonesToReload, ..) >> > >> > In this point I would much prefer something like the >> > partialTriggers-Attribute in trinidad. >> > >> > The thing is you have to define >> > 1. which elements are to be reloaded by AJAX >> > 2. which elements trigger those reloads >> > >> > I could also think of a listener-Component that can be added to the >> > to-be-updated-elements and specify >> > by which components those updates are triggered (which is pretty much >> > the other way around compared to trinidad). >> > >> > I'm not yet completly shure whats the optimal approach for this, but >> > I'll start with writing a s:panelGroup which >> > supports a partialTriggers-Attribute that takes ids of radio-buttons >> > (whith onchange="submit()"). For a start >> > I will integrate this with AJAX-Anywhere to have something to try the >> > different approches for the JSP-Part. >> > Just for playing around whith it. >> > >> > If anyone is interested I'll try to make this online available once >> I'm done. >> > >> > Suggestions, Objections, Ideas and advices are very welcome :-) >> > >> > regards >> > >> > Ernst >> > >> > >> > On 6/15/06, Adam Winer <[EMAIL PROTECTED]> wrote: >> > > I'd be thrilled! >> > > >> > > For background, PPR was developed back before XMLHttp existed. >> > > Back then, the only decent way to communicate to the server was >> > > via hidden iframes. That solution has *a lot* of problems - for >> > > example, no decent way to handle errors, and the document that >> > > comes back can get parsed as HTML, which leads to some ugliness >> > > with handling Javascript, etc.. It was a great choice for the >> time, but >> > > it's showing its age, and there's better technologies >> > > >> > > Swapping out the client-side piece for an XMLHttpRequest-based >> > > submission, with probably a few tweaks to the syntax delivered >> > > by the PPR ResponseWriter, would give us a much more robust >> > > solution, and would be a great isolated task. I'd be more than >> > > happy to point anyone tackling this in the right directions. >> > > >> > > -- Adam >> > > >> > > >> > > On 6/14/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: >> > > > Hi *, >> > > > >> > > > Ernst Fastl - in his SoC beginning review - has worked on >> comparing the >> > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR >> in Trinidad, >> > > > and some of the Avatar approach. >> > > > >> > > > What he's come up with so far is that he really likes the >> server-side >> > > > integration of Trinidad, especially the syntax of integrating >> it in the view >> > > > definition - not so much the client-side portion of it for >> doing PPR. Would >> > > > you be happy with work being done on the client side portion of >> the PPR >> > > > interaction in Trinidad in the SoC project? >> > > > >> > > > regards, >> > > > >> > > > Martin >> > > > >> > > > -- >> > > > >> > > > http://www.irian.at >> > > > >> > > > Your JSF powerhouse - >> > > > JSF Consulting, Development and >> > > > Courses in English and German >> > > > >> > > > Professional Support for Apache MyFaces >> > > > >> > > > >> > > >> > >> >> >> -- >> Matthias Wessendorf >> Aechterhoek 18 >> 48282 Emsdetten >> blog: http://jroller.com/page/mwessendorf >> mail: mwessendorf-at-gmail-dot-com >> > >
