Ok to make this thread endless.
I have spending the last hours going over the codebase over mine and
over the RI.
First the good news, the RI has not changed significantly in the last 2
months, so I assume the JSF API is stable.
To the semi "bad" news:
After looking at everything, I personally would prefer not to use J4Fry
entirely as base but use a merged approach from my code and j4frys.
I will give a reason:
a) J4Fry has a lot of stuff in the core which ultimately is better used
in listeners (the entire disabling of elements, showing progress
indicators). So moving this entire code out into listeners probably has
to be performed anyway.
b) I did a lot of fine grained work regarding the compatibility to the
RI especially in detail areas not fully covered by the spec (context
handling, pass through parameters, detail adjustment in which paramaters
have been moved out of the options and are not dragged into the pass
through params)
c) The entire response ppr handling is specified in the ri and probably
in the spec as is and cannot be altered, hence this probably must be
covered in jsf.js anyway so we have to move that over or have to write
parts from scratch to cover the specs!
In the end I have a small isolated xhr layer which itself has 160 locs
including blanks and comments easily maintainable and fixable with a
fully working queue integrated.
If we strip all the mentioned things from j4fry and move them into
listeners and jsf.js we probably end up with a similar core but a tad
bigger due to bigger abstractions (for me the queue for instance is part
of the transport and the entire queue just is an array!)
But with more work because on one hand we just would rip out the code
needed on the other we have to rework an entire framework core!
So here is my proposal, we stay at my mini core for now (unless there
are serious arguments to drop it) for the xhr aspects but fix things I
might have missed and add some functionality, like being able to limit
the queue size.
Outside of the core implementation we add the listeners, which currently
are in the core functionalitywise to get the disabling enabling and
progressor visualisation in (sort of as a goody addon from myfaces)
We try go get as much from the response handler from j4fry for our own
ppr response handler to minimize work on that part (I wanted to start
with that one as next step anyway). There are probably a lot of things
in j4fry we can reuse.
So in the end it will be a merged codebase from the better parts of both
codebases..
And in the end we can all work on this, I would love to have others also
doing stuff in this area not only entirely me!
Werner
Werner Punz schrieb:
Ganesh schrieb:
Actually it was more along the lines of examples
of what we could reuse from dojo!
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).
Yes I assume so, I personally just find the way the dojo people have
isolated the transport excellent with their xhrRequest objects
and callback functions cleanly isolated and easy to use. It is not an
order that we should integrated it :-)
But I checked out the transport layer a while ago, because I wanted to
reuse it, and that one was pretty hard to rip out! There are so many
dependencies into dojo that
it probably is harder to rip that out than to program your own transport
layer on top of xmlhttprequest :-)
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.
You probably are right there, I was not too deep into the API again this
was just an example of a dojo part which might be useful for us :-)
A small logging api itself is a no brainer and can be done within a
short period of time (i did it in my code as well, with hooks into
console if present if not doing something else)
