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
