MyFaces 2.0 J4Fry first comments

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

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

Re: MyFaces 2.0 J4Fry first comments

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

Ok additional comments,
once the listener interface is again integrated
we probably can move most of the visual code out of the core
into listeners reusable by the user.

(
input field disabling enabling
progress display etc...
)

The result would be that the core is reduced down to the xhr handling
and event handling,

the visual aspects then would be listeners usable within the
jsf2 api!



Werner




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

Re: MyFaces 2.0 J4Fry first comments

[Michael Concini <mc...@gmail.com>]

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

Re: MyFaces 2.0 J4Fry first comments

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

Ganesh schrieb:
> 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).
Yes...

> 
> 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).
> 
execute is more than just the actions and listeners but on the 
javascript side we do not have to bother with it. From the javascript 
perspective it is just an array of ids of existing elements which has to 
be transformend into a blank deliminated string which then has to be 
passed with a certain key (jsf.ajax.partial.execute or so) with the request!

The spec to my knowledge says that the execute ids are the ones being 
processed during execution nothing more...
Anyway it is not the biggest concern for now to me what has to happen on 
the server side.

The issue with execute and render is that certain transformations have 
to be performed upfront before being passed down.
Like values like @all or @none have to be processed (not in the last 
public spec but in the ri) or @form and @this have to be replaced!
The key has to be changed from execute to the jsf.ajax.partial.execute 
parameter!



> 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).
> 
This is ok with me sounds reasonable lets add that one as well I will 
check the last public specs if we can do that...
We probably can keep this under the myfaces umbrella of additional 
options which have to be filtered out!


> - 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.
> 
Extensions is a subproject of myfaces, lets keep all this stuff for now 
in the core codebase and then move it over in the final cleanup phase.
The important part is to push the entire rendering aspect of j4fry into 
respective listener classes which then can be registered by standard jsf 
mechanisms!

Re: MyFaces 2.0 J4Fry first comments

[Ganesh <ga...@j4fry.org>]

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

Re: MyFaces 2.0 J4Fry first comments

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

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

Re: MyFaces 2.0 J4Fry first comments

[Ganesh <ga...@j4fry.org>]

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