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 > >
