myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <>
Subject Re: MyFaces 2.0 AJAX development path
Date Thu, 02 Apr 2009 06:12:42 GMT
Btw. the same what I mentioned about dojo is also true for jquery and 
prototype and any other library.

Lets have in mind what we want to achieve:

a) Send queued asynchronous xhr requests on javascript encoded form data

b) Parse incoming xml

c) Use innerHTML for the incoming static content

d) Use eval for the incoming dynamic content in a safe way so that IE 
does not crash :-)

e) deal with incoming errors correctly

f) deal with listeners in a specified listener interface for various 
stages of the cycle

g) in the long run deal with browser inconsistencies on detail level and 
with portlets and iframe transports (for covering fileuploads)

Where in those areas do third party libs really help?
Almost nowhere except for the xhr request part and some logging, two 
areas too small to add another 50 kybte of code which 95% of it is not used!

My first choice as I said to cover all this was Trinidad but I gave up 
halfway because it simply was too much work to refactor the code down to 
the level I needed, it was basically the same work as to start from 
scratch and build a leaner more maintainable solution and reuse some 
parts of Trinidad!

J4fry in our Jira is similar currently to me as Trinidad was in the 
beginning (a possible candidate due to huge overlap of functionality) 
with the advantage that the developers seem to have done the adjustment 
work already so we just seem to have to do the integration work. But as 
I have to check the code first to see if it is viable for us. If it is 
it would be a good starting base and I could drop my own work! But then 
again I have to have a full integration in our namespace and probably 
some adjustments regarding jsf2!

In the end probably a few weeks of work would be safed for us (which 
wouldnt by using our old Trinidad core, and which would not by 
reimplementation from scratch!

So to give a short summary where I personally stand and why, and it is 
not performance we would not gain anything by using jquery and dojo 
because there are not too many areas where we even could apply their 
query apis (which really are fast)

Dojo: too much functionality we do not need, ripping out the core parts 
we need and integrating them if possible can and should be done. But to 
my experience some parts are hard to isolate due to intra function 
dependencies. Namespace mapping to our namespace for the parts we can 
reuse must be done!

JQuery: everything applies to jquery what was said about dojo, the 
functionality covered by jquery almost to 100% can be found in dojo as well!

Prototype: This is an absolute no go, the framework simply is too 
intrusive, hitchhiking the $ operator without any way out (jquery at 
least has a mode to switch that off), hitchhiking base objects extending 
them. This framework should not be touched with a 10 foot pole.

Trinidad: The overlap is almost 100% functionality wise, but the 
codebase is old and proven. But the core shows its age and needs serious 
cleanup and overhaul to be in line with the spec. Some work was done to 
clean it up, but in the end it was given up by me in favor of a lean 
small and maintainable codebase where parts of Trinidad which were 
needed by the spec were reused!

J4Fry: I will check the code today but the functionality overlap here 
also is almost 100%! And add to that that the maintainers basically did 
on a weekend a jsf2 compatible port of the codebase (which still 
probably needs some adjustments, and we probably get the needed 
undocumented stuff for portlets, fileupload etc...
(Btw. all things not covered by the RI at all)

So I guess everyone can see why my incentive currently goes towards 
dropping my homegrown/trinidad based codebase in favor of j4fry if the 
code quality is good! And why I rather would stay away from the 
integration of the javascript library of choice for now, although I am a 
dedicated fan of those frameworks myself (and use them extensively in my 
own projects:


Andrew Robinson schrieb:
> 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 < 
> <>> 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:
>             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

View raw message