My initial instinct is to +1 for the use of an adapter class to allow
for plugging in different implementations as well.
I've got some time setup next week for my team to sit with the IBM Dojo
experts on Monday to discuss further though, so for now I'm going to
stay in the background while things continue to develop.
Ganesh wrote:
Hi Werner,
95% ack.
1. Having an adapter class would also give all of our dojo, jQuery and
trinidad friends a chance to plugin concurrent implementations and
provide performance tests or other advantages their implemetations
mights have.
2. The listeners are definitely a huge plus against the current spec.
They remove the need for most of the additional attributes described
in MYFACES-2174. Here are the ones that would still be needed:
queuesize, errorlevel and submit. Having them in a subarray
myfaces:{queuesize: (int), errorlevel (warning/error/fatal), submit
(componentIds)} will clarify on that this is beyond the specs. We'll
need to extend the adapter interface to pass the options array. I'll
update MYFACES.2174 on this. For the other options it would be nice to
provide a wrapper function that accepts disable, loadingbar and
postcallback parameters. Which would be the correct place for this
wrapper to go? Provide it together with the MyFaces core? Put it into
tomahawk? Create a separate project, maybe even within J4Fry that
releases a jar containing only this wrapper, so it can be used inside
RI too?
3. Translantion of the comments must done.
I'll go for 1., 2. and 3. during the next few days.
Here's the 5%:
Why these namespace concerns? Isn't org.apache.myfaces the natural
choice? How could this lead to namespace collisions? Actually
myfaces.* is shorter, so it would be ok, too. Please clarify.
Currently I'm working on fixing the request queue, because in J4Fry we
where only using a 1 element queue. Actually I'm missing a reasonable
use case for a bigger AJAX request queue. Imagine a user typing
letters in an input field with each letter queueing an AJAX request
onKeyup. Now, the first request will submit immedately and the engine
starts waiting for the callback. In the meantime the user types 5 more
letters, each of them queueing another request. So, what whould
happen, when the first request has returned? The 2nd request would now
start collecting form values (cannot be done before, because state
might have changed because of request 1), but the input field now
already contains all 6 letters the user has typed. Consequently, all 5
queued requests would submit the same values, thus producing 5
identical xhrs. Do you have an idea which szenario could be targeted
with a queue size > 1?
Best Regards,
Ganesh
Werner Punz schrieb:
Ok I have checked the j4fry code.
So far it looks pretty good to me, well documented and clean and has
worked around a few pitfalls, however some things have to be changed.
I personally would recommend to move the connection between jsf2.js and
the j4fry code into an adapter class, like I did with my code.
The reason is, the adapter class is needed to isolate jsf2 specifics
from the underlying implementation details. Stuff like progress
displays or invalidation of controls and custom options,
should be handled within the adapters as long as they are not specified
explicitely.
The adapter also can isolate jsf2 from the underlying transport and
ppr mechanisms to a certain degree and allows other frameworks to
exchange the transports if the need arises!
(which again would give us an advantage over the RI which has
everything hardcoded into one big class)
So the calling hierarchy is jsf2 api <-> framework adapter with a
clear well defined interface <-> implementation
This also allows us to exchange the underlying frameworks with a
simple switch (like I did for Trinidad and my own implementation)
The implementation can call back into jsf2 (it should not if possible
the adapter should) but jsf2 should not call directly into the
implementation it should call the adapter!
Also not found in the public specs but in the latest ri is a listener
mechanism which notifies the listeners in various stages of the
lifecycle, I assume since the RI has them as public APIs that those
are in later non public specs. I implemented those for exactly this
reason, you basically can copy paste it from me.
Also for the J4Fry specific additonal options, can anyone check in
the latest specs if frameworks are allowed to offer additional
functionality via custom options?
Those should be moved into one single submap under the myfaces
namespace to avoid namespace collissions with public options set by
the user!
Those can be processed and mapped on adapter level, I guess!
So far my first comments on the j4fry code :-)
And last but not least: Namespaces they should be moved over to the
myfaces umbrella, and the comments have to be translated to english.
And please don´t get me wrong, the code quality is excellent! I
really like what I have seen so far...
