Hi all, As an additional info on JSF 2.0, the branch currently don't see much commits because I'm synchronizing it to the latest internal (non-public) spec snapshot.
>From the announced date, that draft along with other minor modifications will become available on April 8th. At that date, I should be able to commit a version of the branch including most of the new API (missing only those added between the internal snapshot and the final draft). So that's roughly two more weeks, giving you (Werner, Ganesh, others) some time to talk about it and/or combine the current solutions without any form of hurry. My personal (not voted on or announced for that matter yet) target for a first alpha release of MyFaces 2.0 is July 1st and that release should include the AJAX module imho as it's one of the most important feature of 2.0. Would that be reasonable for you Werner? Regards, ~ Simon On Thu, Mar 26, 2009 at 8:20 AM, Werner Punz <[email protected]> wrote: > Yes it is nothing more than first steps, this sounds indeed interesting. > The problem I face currently is that I am assigned jobwise to a load of > other tasks so I am not even sure when I will find time for my next commit > on jsf2... > > I will give a short status on what is done: > Currently, unless someone else has added stuff. > The core API of the last spec I could get hold off was implemented APIwise. > > The entire ajax send API itself is already implemented via xhr and a > request queue! I started off by using the core Trinidad Codebase, but ended > with dropping big parts of it by reimplementation and just adding > the parts which didn´t need overhaul one by one. > The situation was simply that parts of the Trinidad codebase implemented a > load of things not needed by the specs, so I ended up supporting both for > now with a small adapter layer! > > What is missing is the response writer for the ajax cycle and the entire > handling of the PPR in the response, unfortunately I wanted to finish this > off a while ago but was assigned to other projects jobwise which had higher > priority! > > So my personal guess is that we are at 70% but... and this is a big but: > > Since I currently do not have clearly dedicated days of being able to do > those things, I am not sure if I can finish the task at all... > That is the sad situation on my side. Although I will try! > And as it seems I will have a few days in April to work on it again, unless > I will get another assignment with higher priority :-( > > > So if anyone wants to take over go ahead... > > Anyway your solution sounds very sophisticated with a lot of browser > bugfixing we probably would have had to do from scratch.. This is indeed an > interesting proposal. > > > > Werner > > > > Matthias Wessendorf schrieb: > > Hey Ganesh, >> >> sounds interesting. Thanks for bringing this up, here! >> >> Werner did already some (first) steps in that direction, based on the >> Trinidad codebase; >> I haven't followed MyFaces 2.0 that close recently, due to some >> workloads... >> >> -Matthias >> >> On Thu, Mar 26, 2009 at 8:16 AM, Ganesh <[email protected]> wrote: >> >>> Dear MyFaces team, >>> >>> From this mailing list I saw you are making progres in the implementation >>> of >>> MyFaces 2.0. However, the AJAX part must be hard to get running. Here is >>> what we would like to propose to you: >>> >>> The J4Fry Team (http://www.j4fry.org) has been developing a JSF AJAX >>> component under the apache >>> 2.0 licence since 2006 to achieve better AJAX JSF integration in business >>> critical software. We have introduced a great amount of stability, >>> cross-browser capability and feature richness in the component. It has >>> been in productive use for years in applications with several thousand >>> users and meets sophisticated non functional requirements. >>> We would love to make it part of MyFaces 2.0. Here is what our AJAX JSF >>> solution has to offer: >>> >>> - PPR (partial page rendering) picks single components out of the >>> JSF tree and triggers their encode() methods >>> - PPS (partial page submit) submits only part of a form and reduces >>> phases 2, 3, and 4 only to the submitted components >>> - Facelets support: We are using an extension of the FaceletsViewHandler >>> to gain access to its buildView method and call it before encoding the >>> components >>> - XHTML and HTML are equally well supported (especially the upper case >>> /lower case differences for tag names) >>> - Portlet support: When accessing the request (to determine the >>> encoding) or the response (to acces the ResponseWriter) we check their >>> types before casting and provide alternative portlet callbacks. We've >>> tested doing AJAX inside a portal with liferay. >>> - Portal support: When running in portals it may be inappropriate to >>> access resouces through the classpath, so we provide a way to define the >>> file path via web.xml >>> - JSF 1.1 and 1.2 comaptibility (tested with MyFaces 1.1.1, 1.1.5, 1.2 >>> and JSF RI 1.2). >>> - Request queing with configurable queue size. The spec requires >>> queueing AJAX request, but doesn't always make sense, so with J4Fry AJAX >>> the size of the queue is configurable. >>> - During the AJAX request we offer a way to disable components either by >>> Id or by type. >>> - J4Fry AJAX accepts a loadingbar attribute pointing to an image that is >>> to show up while the AJAX request is running. >>> - To achieve compatibility with different JSF implementations we search >>> for 5 different keys designating the JSF view state ("jsf_sequence", >>> "jsf_tree_64", "jsf_viewid", "jsf_state_64", "javax.faces.ViewState") >>> - We work around several flaws in IE to allow a cross-browser capable >>> AJAX experience (use insertAdjacentHTML when createContextualFragment >>> isn't available, parse response with VBScript if content-type=iso88591 >>> instead of ISO-8859-1 and run contained scripts after replacing HTML >>> elements) >>> - We've tested AJAX on IE 5.5 - IE 7, FF 2-3, Safari and Opera >>> - Our solution comprises 1057 lines of Javascript code and 1073 lines of >>> Java code (a great part of the Java code implements a declarative >>> solution >>> that won't be required for JSF 2.0 compatibility) >>> - The entire solution is designed and implemented to achieve high >>> performance >>> - Our sourceforge downloads are approaching the 3000 >>> (https://sourceforge.net/search/?type_of_search=soft&words=j4fry). >>> - We are personally supporting 7 productive systems that are using our >>> components. >>> - We've run J4Fry AJAX on Tomcat, BEA and Glassfish. >>> - Here's a link to out AJAX documentation: >>> http://www.j4fry.org/jsfAjax.shtml >>> - We're a completely non-commercial community of JSF developers with >>> dependencies of no company whatsoever. >>> >>> To do: >>> - Separate J4Fry AJAX from the rest of J4Fry's JSF components >>> (see http://www.j4fry.org/jsfComponents.shtml) >>> - Create a JSF 2.0 spec compatible interface. >>> - Reorganize package structure to fit MyFaces 2.0 >>> - Translate comments in our the Javascript files from german to english >>> >>> The main AJAX commiters in our team are Alex Bell and Ganesh Jung. Both >>> are located in Munich, Germany and would volunteer to do the integration >>> work as well as testing and future support. Most of the J4Fry developers >>> are located in germany. >>> There must be an team that is already working on MyFaces 2.0 AJAX. We are >>> willing to integrate with the existing personal structures to find a >>> common >>> cooperative base with the goal of making MyFaces 2.0 AJAX the best AJAX >>> of JSF 2.0 implematations! >>> Please tell us, whether you are welcoming our cooperation. >>> >>> Best Regards, >>> Ganesh Jung >>> >>> >>> >> >> >> >
