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 Wed, 01 Apr 2009 19:49:29 GMT
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.


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