Re: MyFaces 2.0 AJAX development path
Ganesh
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
Tomorrow I'll post 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 an equal state.
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
>>
>>
>