Hi,
- Fine, lets go for namespace myfaces.
- I think I have to clarify on the parameters render, execute and
(optional) myfaces.submit:
render, I think we are d'accord on this, will affect the components
triggered for rendering during render response on the Java side and it
will determine the HTML elements to replace on the Javascript side (this
is PPR).
execute will determine, which links or buttons action and
actionsListeners will be triggered. It add the buttons or links
name=value to the POST params on the Javascript side and influences the
invoke application phase on the Java side (this is neither PPR nor PPS,
it's a JSF specificum).
myfaces.submit influences the way POST parameters are collected on the
Javascript side. Instead of merely piling up all the parameters of a
form it recurses through the DOM tree and adds only those branches that
are designated in the myfaces.submit parameter through their parent
element. On the Java side this reduce apply request values and update
model to the branches of the component tree that where submitted before
(this is PPS).
- Where do I find the extensions package? I think this would be a great
place for the view params disable, loadingbar and postJSFuntion to go.
Best Regards,
Ganesh
Werner Punz schrieb:
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...
