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
