> " As I said I am not very much in favor of a full dojo dependency although I personally love dojo."
+1. On Wed, Apr 1, 2009 at 9:49 PM, Werner Punz <[email protected]> wrote: > Cool down guys :-) > No seriously I have stated already why I personally would > prefer not to get a direct dojo dependency into the myfaces core. > However, I am fine with having ported useful code over from Dojo > into the core. > > So my proposal is following: > > -1 to a dojo dependency in the myfaces core. I personally thing > the dojo dependency in Tomahawk was evil enough and I am still working on > getting it out into a separate component lib! > > Also the namespace in the core must be under the core javax and myfaces > namespaces no external namespaces should be allowed to avoid namespace > clashes. The namespacing also should follow the jsf2 conventions of using > maps and using the openajax api! > > +1 if someone finds something useful we can take it from the dojo core lib > but must adhere to the dojo license (license.txt with the dojo bsd license > and references in the code should be suffice) > > Can anyone live with that? I personally for instance would love to have the > dojo transport and logging layer being isolated out of dojo to be reused > that stuff simply is phantastic but with a full dojo dependency for me this > would be a no go... > > As I said I am not very much in favor of a full dojo dependency although I > personally love dojo. > > > > Werner > > > > > Ganesh schrieb: > > Hi Michael, >> >> Yes, I agree, Dojo is extremely cool. If I had to start of with an AJX >> JSF solution from scratch I would certainly do this based on Dojo. I'm >> currently making up some Facelets templates for Dojo JSF integration >> (just a playground: >> http://www.j4fry.org/JSFExamples/faces/dojoFacelets/index.xhtml) and >> it's great fun! It's also good to hear that there are more people >> willing to help with the MyFaces 2.0 AJAX. >> >> I think the primary problem is not doing some xhr in a queue and >> processing of the callbacks. This has become standard stuff Trinidad and >> Dojo and RI 2.0 AJAX and J4Fry do in a very similar way. The difference >> is the way that J4Fry AJAX is integrated with JSF from scratch. In >> detail there is: >> >> * JSF ViewState processing >> * Component oriented processing of the HTML replacements >> * Submit parameters that trigger invoke application and render >> response phases >> * Parameters beyond the scope of the spec for PPS and several >> further features crucial for a good JSF AJAX experience >> * Javascript code is already ported to JSF 2.0 and has been tested >> against RI 2.0 >> * Java code for server side processing has been running with JSF 1.2 >> for a long time and waits for the JSF 2.0 port >> * JSR 168 portlet support >> >> I've also opened a jira for a list of features for JSF integration that go >> far beyond the spec. These features weren't just implemented for JSF 2.0, >> they have been productive in high performance business critical >> applications for years. >> >> Implementing all of this from scratch based on dojo xhr is surely >> possible, but it would probably take time to reach the necessary code >> quality. >> >> Best Regards, >> Ganesh >> >> Michael Concini schrieb: >> >>> Sorry I'm a little late to the discussion here, but I'm a little >>> concerned with the direction here. I'm not very familiar with the >>> advantages or disadvantages of J4Fry, but I do know that we're not familiar >>> with the state of the J4Fry code. We do know Dojo is a mature release with >>> top level performance and accessibility features. In addition, Dojo is a >>> very well known framework with a large and dedicated developer community >>> surrounding it. What does J4Fry offer that Dojo cannot? >>> >>> If the concern is developer resources, we have a team of developers at >>> IBM who are very active in the Dojo community and who have offered their >>> assistance to my team in porting the necessary code to MyFaces. The license >>> is really not a concern, as Dojo code is already being included in at least >>> Apache project. As long as you mention in your code comments that the code >>> was ported from Dojo under the BSD license you shouldn't need to do anything >>> else. >>> I think it would be worthwhile to have a discussion among the community >>> about which framework would be best to utilize going forward. >>> >>> Thanks, >>> Mike >>> >>> Ganesh wrote: >>> >>>> 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 >>>> >>>> >>>> >>> >> >> > -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/tt/articles/article.tss?l=IntroductiontoGMaps4JSF
