Hi Werner, I've been reading the current MyFaces 2.0 AJAX code. I want to try and share my concerns on 4 subjects:
1. The collecting of form parameters will need some refinement: getFormMap doesn't care for upper/lower case of tagname and type though differ per browser and between HTML/XHTML. getFormMap contains the comment "todo: do not post values for non-triggering submit buttons" 2. Response processing not implemented: The complete PPR part is still missing. Different trinidad functions exist to process XML and Text, but the code doesn't say anything yet about the format of the XML response that is to be sent back.We probably cannot rely on valid XML here, because the response may contain parts of a JSP that aren't valid XML (like, for example, <f:verbatim><br></f:verbatim>). Have you already defined a XML format we could use for transport? I think it could be good idea to use the same format as the RI does to make the AJAX libraries exchangeable. 3. dojo cross-port: The JSF2Utils class consists mostly of copied dojo code. Doesn't this pose a licensing problem if you put it under the apache 2 license? I had a look into the dojo licenses: They dual-license under bsd and afl and both have different requirements if you want to copy and change their source code. Here's what I found: bsd: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. afl: Licensor hereby agrees to provide a machine-readable copy of the Source Code of the Original Work along with each copy of the Original Work that Licensor distributes. 4. Trinidad code needs further cleanup: There are lots of functions like myfaces._TrRequestQueue.prototype._doRequestThroughIframe that refer to the old AJAX over IFRAME of ADF Faces which is not required for JSF 2.0. In my understanding of the code it consists of 4 major parts: - Trinidad RequestQueue - Dojo Javascript fiddling - OpenAjax - JSF2.0 spec. impl. parts What I want to suggest is to replace the trinidad and dojo parts with repackaged J4Fry. It would take me less work to get the repackaged J4Fry stuff running instead of trying to squeeze it into the dojo/trinidad code. Would this be an appropriate and acceptable approach for you? Alex and me could try and get this done within a few days. My other point is: Why do you use a servlet for testing? We could use the RI to test the Javascript against and then move to the Java part with pretested Javascript. This way we would also ensure full compatibility of the XML formats used by both implementations. The only point one could make is about size. If the RI's XML format turns out to be quite talkative we could think about using a more performant format. For this reason J4Fry was originally using JSON but the spec explicitly dictates the use of XML here (god knows why ...). What do you think? Best Regards, Ganesh
