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
