Whoops, wrong #, jquery is 56K not 19K. GZip size is jQuery 19KB, Dojo 27K
-Andrew On Wed, Apr 1, 2009 at 4:27 PM, Andrew Robinson < [email protected]> wrote: > I have a different suggestion. > > Each proponent(s) of a 3rd party AJAX solution, create a WIKI page on the > apache website with PROS and CONS for that library. In that WIKI, include a > gap analysis of the library vs. the JSF2 spec. requirements. Also mention > speed performance and download performance (size) and also flexibility and > maintainability. > > Then once these WIKIs are complete enough, the dev@ community can use them > as a discussion point on one or another. I just think an email thread for > this is not the right solution until the full picture is seen for each > library. > > I'm surprised no one has mentioned jQuery since Dojo keeps getting > mentioned, as jQuery currently has some of the fastest performing code for > XPath-like page lookups. Not to mention jQuery is 19KB where Dojo is 80KB > > -Andrew > > > On Wed, Apr 1, 2009 at 3:31 PM, Ganesh <[email protected]> wrote: > >> Hi, >> >> I'm sorry if I was sounding "hot". It's just that I'd really love the JSF >> AJAX code we've been crafting and refining for years at J4Fry to go into >> MyFaces and I think there are reasonable arguments for this. I'm only trying >> to bring them forward with the hope of convincing everyone ;-) >> >> Dojo code is cool and it's hype, so if there is anything we can use from >> it that'll be great. License is probably a minor issue here. What exactly do >> you mean: "transport and logging layer"? >> >> My understanding of transport is that it is hardly more that instantiating >> an xmlhttprequest and queueing the callback. I'm afraid "crossporting" the >> dojo code wouldn't do a great deal of change to the code as it's pretty much >> the same in many AJAX implementations including J4Fry and trinidad (please >> correct me of the parts if I'm overseeing here). >> >> The logging part in dojo in really good - but it depends on firebug! Would >> you want to include firebug lite with MyFaces??? I'm not quite sure of the >> size of it and it certainly needs lots of improvement and bugfixing and the >> state we put into MyFaces would be frozen - we would need to crossport new >> releases as they evolve. >> >> As you see there are several doubts on my side, but I would be happy if >> you enlightened me in understanding the exact meaning of what you where >> suggesting. >> >> Best Regards, >> Ganesh >> >> >> >> Werner Punz schrieb: >> >> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >
