Re: MyFaces 2.0 AJAX development path

[Werner Punz <we...@gmail.com>]

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.
> 

Sorry for jumping in late again, but the last days I was in "sickbay" 
with a flu.

Hello I also was working on an implementation as it seems, the J4Fry 
people have surpassed me in this regard, so I might drop my part and 
will take over from what I will get from the J4Fry people.

I have to check their code first and will probably do some adjustments!
Since I have not seen of what they have done so far, I will have to do a 
checkup once parts of their work are submitted into the jira!

But now for Dojo:

I am as well knee deep into Dojo, and my opinions especially regarding 
the Dojo core (the dijit widgets somewhat less due to bugs) is very 
high, but in my code I did not use it. Lets talk seriously about Dojo, 
and what it has to offer and where the problems are using it.

Dojo offers a lot, but is it really a good base for our implementation.
First of all we have a base library which means we should not introduce 
a dependency against another library widely used we have to map 
everything into the jsf namespace.
(I think dojo can remap namespaces but I have to recheck that)

The dojo core itself is 50kbyte compressed with a lot of things we do 
not need, what we would need mostly for jsf 2.0 is the dojo transport 
layer only, nothing else. It is hard to isolate that one out! The other 
thing is dojo.hitch, which can be ripped out (and is by me in the code I 
committed) and maybe the log layer!


The dojo ppr itself is a totally different issue, and mechanism, because 
it relies on parsing on the javascript side and frankly spoken, works 
entirely different to jsf.

JSF needs a ResponseWriter and a separate eval for the embedded scripts
while dojo relies on parsing of the client side tags regarding 
attributes, so we cannot recycle that one (which would be a huge benefit).

As for ppr and dojo, I dont see to many clashes here, the jsf namespace 
and dojo namespace are two different entities, so if we avoid that one
so mixing both things should be a no brainer.
(I did a ppr of dojo based components based on Trinidad, in my still due 
to time constraints not yet opensourced dojo components jsf project)

So what would speak for dojo:
a) a nice transport layer api which we could recycle
and some nice apis doing some isolation in the dom handling!

What would speak against dojo:

a) A moving target beyound our control with probable name clashes, 
unless we can remap the namespaces

b) 50 kbytes extra includes we have to drag along unless it is possible 
to isolate the transport only code (which is hard because dojo is so 
interwined with each other)


The probably best way to resolve all this might be to isolate the entire 
transport handling so that third party libraries can be plugged in, from 
the rest of the jsf2 spec we would not get too much support anyway!

Another thing could be we could isolate the parts of dojo we need and 
take them into our own code, which would make sense, but the isolation 
of code from the core itself is very hard and time consuming due to the 
intra function dependencies within the core!

But in the end keep in mind, keep things as small as possible, one 
reason why I tried to phase out the Trinidad code I used upfront in my 
first implementation trials, there were too many things in there which 
needed some cleanup and isolation and which we did not need in the first 
place!
But what we definitely have to achieve is to keep things clean and try 
to avoid any clashes into third party libs or sideeffects into them!

Ok just my 2c regarding the usage of dojo. As I said I can live with it 
but more along being able to hook another tansport adapter/provider 
instead of hooking it as dependency into the core!



Just my 2c...

Werner