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: http://tutorials.irian.at/book_de/introduction.html)
Werner
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 <[email protected]
<mailto:[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
