Ganesh schrieb:
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.
Yes definitely... I think the core implementation parts should be
pluggable...
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)}
Ok errorlevel can be kept submit definitely not, this is covered in the
standard option parameter execute (which covers a list of component ids
to be executed) and also the render paramter covers the list of
component ids to be processed by the response drawing.
will
clarify on that this is beyond the specs. We'll need to extend the
adapter interface to pass the options array.
Actually what I would propose is to use my jsf.js which is basically the
outer core, doing al the execute and render preprocessing and hook
yourself into their with your own adapter...
That way we can cover the standard stuff (like how the render and
execute ids have to be collected and converted)
and then on your side you can do additonal processing.
What I would say, for non standard staff we can follow the jsf way
but adding our own myfaces submap to the options which allow to add
additional parameters which are implementation dependend..
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?
Actually I probably would add simply a set of listener function classes
instances of them then can be added to the listener queue on the fly...
The implementation specifics then are just a matter of implementing the
interface needed to call the listeners.
The place could be in the impl package somewhere, or our extension project.
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.
It is myfaces for now, we can rechange that simply by using a regexp...
It used to be org.apache.myfaces but it was too long for my taste.
Especiall also since org is a generic root so using that as root
via openajax cannot be reserved to apache or myfaces, hence myfaces and
nothing else!
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?
One thing instantly comes to mind, dynamic scrolling...
Or short inputs affecting two different forms, also
real time validation of input text comes to mind where this szenario
definitely is better with a long queue and yet stil must perform
asynchronously.
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...
