Re: f:ajax and MyFaces extensions
On Fri, Apr 24, 2009 at 9:17 AM, Ganesh gan...@j4fry.org wrote: Hi, With all the community feedback in favour of t:ajax I gave it some more thought and came up with a solution: tomahawk can bring it's own myfaces.js file that t:ajax builds on. This solution does have a whole bunch of benefits: - the optimization options become available to Mojarra users - Mojarra Javascript bugs don't affect t:ajax users - view options like disable (naming elements to disable while xhr runs) and loadingbar (a turning snake to display while xhr is running) can be integrated with t:ajax - the options can be used naturally t:ajax execute=... render=... pps=... disable=.../, no more need for a myfaces subarray - defaulting can include pps=true and queuesize=1 - myfaces.js would include a function myfaces.ajax.request that is triggered by t:ajax. The parameters of myfaces.ajax.request could also be set up more naturally, the need for a myfaces subarray would drop out: myfaces.ajax.request(execute:... render:... pps:... disable:...), thus aligning the procedural and the declarative solution If we decide to go this way I would remove the special options from the cores Javascript too. We've got 4 different proposed solutions now: 1.) extra options in t:ajax and myfaces.ajax.request 2.) optimization options as attributes of f:ajax 3.) optimization options within f:attributes nested in f:ajax 4.) a separate taglibrary with a single tag mf:ajax included with the core Should I set up a vote on this? please! You already know my vote, right ? :) Best Regards, Ganesh Cagatay Civici schrieb: Then just document t:ajax is an extension that's not compatible with RI. On Thu, Apr 23, 2009 at 5:39 PM, Ganesh gan...@j4fry.org mailto:gan...@j4fry.org wrote: Hi, The options don't work with the RI, so t:ajax isn't feasable afaik. Best Regards, Ganesh Cagatay Civici schrieb: The legacy way myfaces followed for a long time is to have standards in core and extensions in tomahawk. Isn't it the whole idea of t:inputText, t:dataTable? So I'm -1 as well for that kind of extensions in core so t:ajax sounds fine. Cagatay On Thu, Apr 23, 2009 at 5:06 PM, Ganesh gan...@j4fry.org mailto:gan...@j4fry.org mailto:gan...@j4fry.org mailto:gan...@j4fry.org wrote: Hi, How would you get the options into tomahawk? They rely on the Javascript core and tomahawk needs to run with the RI. What is myfaces:ajax? Is it another namespace included with the core, containing only a single tag? It seems confusing for the users to have additional options available on jsf.ajax.request which cannot be triggered when using the declarative approach without adding an extensions jar. Best Regards, Ganesh Werner Punz schrieb: Sorry I have not read the original post here I agree with Simon in the regard, that we should not add the options thing to our standard f:ajax tag, but would go even further to add nothing to f:ajax at all which is outside of the spec! The reason for this is, it would break the behavior we have done in the past and people relied upon. Up until now we added extensions on tag level via our own tag(Partially enforced by the TCK) So -1 to adding anything custom to f:ajax +1 to enable the users to access our internal custom options with myfaces:ajax or t:ajax Sorry for my lengthy post before, which was semi off topic, I should had read the entire conversation before posting a reply. Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION With this option set some applications may add non serializable beans to the state, breaking compatibility with other implementations. It is obvious to the developer that options starting with myfaces can induce compatibility problems. Imho you hit the point when you said before that core extensions should be avoided if they do fundamentally change the behaviour of the app. Standard applications should be remain portable in spite of implementation
Re: f:ajax and MyFaces extensions
Ok let me get this straight... You propose to route to our jsf_impl if a mojarra user tries to use the tag. That needs some adjustments, because we call jsf.js from within our _impl code. So we need to add a loose coupling of those calls as well by adding an adaptor/delegator pattern for those! (I am thinking of adding another configuration option which can change the namespace of the api callback so that we can reroute them directly into our impl_ class on the fly) I am ok with it... so +1 from my side, I dont expect any sideffects if we can straighten this out! Anway it seems that this is the usecase where we first see the advantages of being modular and loosely coupled in our code instead of trying to push everything into jsf.js :-) Werner Ganesh schrieb: Hi, With all the community feedback in favour of t:ajax I gave it some more thought and came up with a solution: tomahawk can bring it's own myfaces.js file that t:ajax builds on. This solution does have a whole bunch of benefits: - the optimization options become available to Mojarra users - Mojarra Javascript bugs don't affect t:ajax users - view options like disable (naming elements to disable while xhr runs) and loadingbar (a turning snake to display while xhr is running) can be integrated with t:ajax - the options can be used naturally t:ajax execute=... render=... pps=... disable=.../, no more need for a myfaces subarray - defaulting can include pps=true and queuesize=1 - myfaces.js would include a function myfaces.ajax.request that is triggered by t:ajax. The parameters of myfaces.ajax.request could also be set up more naturally, the need for a myfaces subarray would drop out: myfaces.ajax.request(execute:... render:... pps:... disable:...), thus aligning the procedural and the declarative solution If we decide to go this way I would remove the special options from the cores Javascript too. We've got 4 different proposed solutions now: 1.) extra options in t:ajax and myfaces.ajax.request 2.) optimization options as attributes of f:ajax 3.) optimization options within f:attributes nested in f:ajax 4.) a separate taglibrary with a single tag mf:ajax included with the core Should I set up a vote on this? Best Regards, Ganesh Cagatay Civici schrieb: Then just document t:ajax is an extension that's not compatible with RI. On Thu, Apr 23, 2009 at 5:39 PM, Ganesh gan...@j4fry.org mailto:gan...@j4fry.org wrote: Hi, The options don't work with the RI, so t:ajax isn't feasable afaik. Best Regards, Ganesh Cagatay Civici schrieb: The legacy way myfaces followed for a long time is to have standards in core and extensions in tomahawk. Isn't it the whole idea of t:inputText, t:dataTable? So I'm -1 as well for that kind of extensions in core so t:ajax sounds fine. Cagatay On Thu, Apr 23, 2009 at 5:06 PM, Ganesh gan...@j4fry.org mailto:gan...@j4fry.org mailto:gan...@j4fry.org mailto:gan...@j4fry.org wrote: Hi, How would you get the options into tomahawk? They rely on the Javascript core and tomahawk needs to run with the RI. What is myfaces:ajax? Is it another namespace included with the core, containing only a single tag? It seems confusing for the users to have additional options available on jsf.ajax.request which cannot be triggered when using the declarative approach without adding an extensions jar. Best Regards, Ganesh Werner Punz schrieb: Sorry I have not read the original post here I agree with Simon in the regard, that we should not add the options thing to our standard f:ajax tag, but would go even further to add nothing to f:ajax at all which is outside of the spec! The reason for this is, it would break the behavior we have done in the past and people relied upon. Up until now we added extensions on tag level via our own tag(Partially enforced by the TCK) So -1 to adding anything custom to f:ajax +1 to enable the users to access our internal custom options with myfaces:ajax or t:ajax Sorry for my lengthy post before, which was semi off topic, I should had read the entire conversation before posting a reply. Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION
Re: f:ajax and MyFaces extensions
To just add my personal comment. Those options are discussed for a reason. There are problems within the realm of the spec that some corner cases have not been really covered which normally do not occur but from time to time happen (like issues with infinite queue sizes under certain application environments, or for instance in the future dealing with fieluploads before jsf 2.1, or for instance I just added an option to allow other error outputs for development besides alert (like it was defined in the spec) for Development stage) We saw it sort of necessary to allow the users to enable those options because it is better to allow sane overrides at certain points than to force the user to hack the code to get some features up and running for certain corner cases. (which is always possible with javascript due to no having any isoltion whatsoever) As for the portability trap, I dont really see it, everyone who uses a custom option must be aware that this might induce a portability problem in the long run, but this option has to be used fully understanding it since it is outside of the spec, and leaving them out definitely has to cause a fully spec compliant behavior! Besides that the entire configuration stuff is used in two different areas to give a short explanation we have a global configuration which also binds the layers (mainly api-impl-delegators for impl, and also allows to enable settings on a global level) we have local configuration options which can override the global ones to allow settings on a local per request layer! So what does this mean, first of all, none of this should be used in normal circumstances, in this case we should be fully spec compliant but then you can alter certain things on a need to need base, like changing the spec alert behavior to console.log for debugging purposes, or you can change your impl on the fly with a different one, or you can change the currently dependency less xhr transport delegate to a dojo based one, if preferred, or you can alter the queue size. We are simply opting for such things because of corner cases and to leave the users/companies using the code options open to add their own implementations without having to hack the code. But everyone doing such things must be aware of the risks this might introduce! This is not the first time we are doing this, as pointed out earlier, we have in other points those configuration options as well, just look at the list of context parameters myfaces provides to enable certan behavior like controlling the state history, or as below pointed out to how the serialisation has to be performed! Nothing of those has introduced any portability issues so far because people understood that this was behavior which should ease the life but is outside of the spec! Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION With this option set some applications may add non serializable beans to the state, breaking compatibility with other implementations. It is obvious to the developer that options starting with myfaces can induce compatibility problems. Imho you hit the point when you said before that core extensions should be avoided if they do fundamentally change the behaviour of the app. Standard applications should be remain portable in spite of implementation options set. Here's a short discussion on the portability issues of the proposed extension options: - With myfaces:pps set to true applications that evaluate request parameters within phase 5 could change their behaviour. - With myfaces:errorlevel set to WARNING applications that have a Javascript part that relies on some errorlisteners being triggered could change behaviour. - With myfaces:queuesize set to 1 it's hard to think of an application that would change behaviour. Maybe a button that increases a counter by 1 (or scrolls a list by 1 page) on each click would miss some of the clicks if the user has a quick thumb. I cannot think of a szenario where myfaces:queuesize=1 would make an application run into errors (can you?). I think all 3 of these are special cases where minor changes of behaviour occur, none of them fundamentally changes the behaviour of the app. Best Regards, Ganesh Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created.
Re: f:ajax and MyFaces extensions
Sorry I have not read the original post here I agree with Simon in the regard, that we should not add the options thing to our standard f:ajax tag, but would go even further to add nothing to f:ajax at all which is outside of the spec! The reason for this is, it would break the behavior we have done in the past and people relied upon. Up until now we added extensions on tag level via our own tag(Partially enforced by the TCK) So -1 to adding anything custom to f:ajax +1 to enable the users to access our internal custom options with myfaces:ajax or t:ajax Sorry for my lengthy post before, which was semi off topic, I should had read the entire conversation before posting a reply. Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION With this option set some applications may add non serializable beans to the state, breaking compatibility with other implementations. It is obvious to the developer that options starting with myfaces can induce compatibility problems. Imho you hit the point when you said before that core extensions should be avoided if they do fundamentally change the behaviour of the app. Standard applications should be remain portable in spite of implementation options set. Here's a short discussion on the portability issues of the proposed extension options: - With myfaces:pps set to true applications that evaluate request parameters within phase 5 could change their behaviour. - With myfaces:errorlevel set to WARNING applications that have a Javascript part that relies on some errorlisteners being triggered could change behaviour. - With myfaces:queuesize set to 1 it's hard to think of an application that would change behaviour. Maybe a button that increases a counter by 1 (or scrolls a list by 1 page) on each click would miss some of the clicks if the user has a quick thumb. I cannot think of a szenario where myfaces:queuesize=1 would make an application run into errors (can you?). I think all 3 of these are special cases where minor changes of behaviour occur, none of them fundamentally changes the behaviour of the app. Best Regards, Ganesh Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created.
Re: f:ajax and MyFaces extensions
Hi, How would you get the options into tomahawk? They rely on the Javascript core and tomahawk needs to run with the RI. What is myfaces:ajax? Is it another namespace included with the core, containing only a single tag? It seems confusing for the users to have additional options available on jsf.ajax.request which cannot be triggered when using the declarative approach without adding an extensions jar. Best Regards, Ganesh Werner Punz schrieb: Sorry I have not read the original post here I agree with Simon in the regard, that we should not add the options thing to our standard f:ajax tag, but would go even further to add nothing to f:ajax at all which is outside of the spec! The reason for this is, it would break the behavior we have done in the past and people relied upon. Up until now we added extensions on tag level via our own tag(Partially enforced by the TCK) So -1 to adding anything custom to f:ajax +1 to enable the users to access our internal custom options with myfaces:ajax or t:ajax Sorry for my lengthy post before, which was semi off topic, I should had read the entire conversation before posting a reply. Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION With this option set some applications may add non serializable beans to the state, breaking compatibility with other implementations. It is obvious to the developer that options starting with myfaces can induce compatibility problems. Imho you hit the point when you said before that core extensions should be avoided if they do fundamentally change the behaviour of the app. Standard applications should be remain portable in spite of implementation options set. Here's a short discussion on the portability issues of the proposed extension options: - With myfaces:pps set to true applications that evaluate request parameters within phase 5 could change their behaviour. - With myfaces:errorlevel set to WARNING applications that have a Javascript part that relies on some errorlisteners being triggered could change behaviour. - With myfaces:queuesize set to 1 it's hard to think of an application that would change behaviour. Maybe a button that increases a counter by 1 (or scrolls a list by 1 page) on each click would miss some of the clicks if the user has a quick thumb. I cannot think of a szenario where myfaces:queuesize=1 would make an application run into errors (can you?). I think all 3 of these are special cases where minor changes of behaviour occur, none of them fundamentally changes the behaviour of the app. Best Regards, Ganesh Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created.
Re: f:ajax and MyFaces extensions
The legacy way myfaces followed for a long time is to have standards in core and extensions in tomahawk. Isn't it the whole idea of t:inputText, t:dataTable? So I'm -1 as well for that kind of extensions in core so t:ajax sounds fine. Cagatay On Thu, Apr 23, 2009 at 5:06 PM, Ganesh gan...@j4fry.org wrote: Hi, How would you get the options into tomahawk? They rely on the Javascript core and tomahawk needs to run with the RI. What is myfaces:ajax? Is it another namespace included with the core, containing only a single tag? It seems confusing for the users to have additional options available on jsf.ajax.request which cannot be triggered when using the declarative approach without adding an extensions jar. Best Regards, Ganesh Werner Punz schrieb: Sorry I have not read the original post here I agree with Simon in the regard, that we should not add the options thing to our standard f:ajax tag, but would go even further to add nothing to f:ajax at all which is outside of the spec! The reason for this is, it would break the behavior we have done in the past and people relied upon. Up until now we added extensions on tag level via our own tag(Partially enforced by the TCK) So -1 to adding anything custom to f:ajax +1 to enable the users to access our internal custom options with myfaces:ajax or t:ajax Sorry for my lengthy post before, which was semi off topic, I should had read the entire conversation before posting a reply. Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION With this option set some applications may add non serializable beans to the state, breaking compatibility with other implementations. It is obvious to the developer that options starting with myfaces can induce compatibility problems. Imho you hit the point when you said before that core extensions should be avoided if they do fundamentally change the behaviour of the app. Standard applications should be remain portable in spite of implementation options set. Here's a short discussion on the portability issues of the proposed extension options: - With myfaces:pps set to true applications that evaluate request parameters within phase 5 could change their behaviour. - With myfaces:errorlevel set to WARNING applications that have a Javascript part that relies on some errorlisteners being triggered could change behaviour. - With myfaces:queuesize set to 1 it's hard to think of an application that would change behaviour. Maybe a button that increases a counter by 1 (or scrolls a list by 1 page) on each click would miss some of the clicks if the user has a quick thumb. I cannot think of a szenario where myfaces:queuesize=1 would make an application run into errors (can you?). I think all 3 of these are special cases where minor changes of behaviour occur, none of them fundamentally changes the behaviour of the app. Best Regards, Ganesh Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created.
Re: f:ajax and MyFaces extensions
Hi, The options don't work with the RI, so t:ajax isn't feasable afaik. Best Regards, Ganesh Cagatay Civici schrieb: The legacy way myfaces followed for a long time is to have standards in core and extensions in tomahawk. Isn't it the whole idea of t:inputText, t:dataTable? So I'm -1 as well for that kind of extensions in core so t:ajax sounds fine. Cagatay On Thu, Apr 23, 2009 at 5:06 PM, Ganesh gan...@j4fry.org mailto:gan...@j4fry.org wrote: Hi, How would you get the options into tomahawk? They rely on the Javascript core and tomahawk needs to run with the RI. What is myfaces:ajax? Is it another namespace included with the core, containing only a single tag? It seems confusing for the users to have additional options available on jsf.ajax.request which cannot be triggered when using the declarative approach without adding an extensions jar. Best Regards, Ganesh Werner Punz schrieb: Sorry I have not read the original post here I agree with Simon in the regard, that we should not add the options thing to our standard f:ajax tag, but would go even further to add nothing to f:ajax at all which is outside of the spec! The reason for this is, it would break the behavior we have done in the past and people relied upon. Up until now we added extensions on tag level via our own tag(Partially enforced by the TCK) So -1 to adding anything custom to f:ajax +1 to enable the users to access our internal custom options with myfaces:ajax or t:ajax Sorry for my lengthy post before, which was semi off topic, I should had read the entire conversation before posting a reply. Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION With this option set some applications may add non serializable beans to the state, breaking compatibility with other implementations. It is obvious to the developer that options starting with myfaces can induce compatibility problems. Imho you hit the point when you said before that core extensions should be avoided if they do fundamentally change the behaviour of the app. Standard applications should be remain portable in spite of implementation options set. Here's a short discussion on the portability issues of the proposed extension options: - With myfaces:pps set to true applications that evaluate request parameters within phase 5 could change their behaviour. - With myfaces:errorlevel set to WARNING applications that have a Javascript part that relies on some errorlisteners being triggered could change behaviour. - With myfaces:queuesize set to 1 it's hard to think of an application that would change behaviour. Maybe a button that increases a counter by 1 (or scrolls a list by 1 page) on each click would miss some of the clicks if the user has a quick thumb. I cannot think of a szenario where myfaces:queuesize=1 would make an application run into errors (can you?). I think all 3 of these are special cases where minor changes of behaviour occur, none of them fundamentally changes the behaviour of the app. Best Regards, Ganesh Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created.
Re: f:ajax and MyFaces extensions
On Thu, Apr 23, 2009 at 6:39 PM, Ganesh gan...@j4fry.org wrote: Hi, The options don't work with the RI, so t:ajax isn't feasable afaik. +1 f:ajax ++ OR mf:ajax (which is just shipped with myfaces) doing an independent library is pretty much too much... IMO -M Best Regards, Ganesh Cagatay Civici schrieb: The legacy way myfaces followed for a long time is to have standards in core and extensions in tomahawk. Isn't it the whole idea of t:inputText, t:dataTable? So I'm -1 as well for that kind of extensions in core so t:ajax sounds fine. Cagatay On Thu, Apr 23, 2009 at 5:06 PM, Ganesh gan...@j4fry.org mailto:gan...@j4fry.org wrote: Hi, How would you get the options into tomahawk? They rely on the Javascript core and tomahawk needs to run with the RI. What is myfaces:ajax? Is it another namespace included with the core, containing only a single tag? It seems confusing for the users to have additional options available on jsf.ajax.request which cannot be triggered when using the declarative approach without adding an extensions jar. Best Regards, Ganesh Werner Punz schrieb: Sorry I have not read the original post here I agree with Simon in the regard, that we should not add the options thing to our standard f:ajax tag, but would go even further to add nothing to f:ajax at all which is outside of the spec! The reason for this is, it would break the behavior we have done in the past and people relied upon. Up until now we added extensions on tag level via our own tag(Partially enforced by the TCK) So -1 to adding anything custom to f:ajax +1 to enable the users to access our internal custom options with myfaces:ajax or t:ajax Sorry for my lengthy post before, which was semi off topic, I should had read the entire conversation before posting a reply. Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION With this option set some applications may add non serializable beans to the state, breaking compatibility with other implementations. It is obvious to the developer that options starting with myfaces can induce compatibility problems. Imho you hit the point when you said before that core extensions should be avoided if they do fundamentally change the behaviour of the app. Standard applications should be remain portable in spite of implementation options set. Here's a short discussion on the portability issues of the proposed extension options: - With myfaces:pps set to true applications that evaluate request parameters within phase 5 could change their behaviour. - With myfaces:errorlevel set to WARNING applications that have a Javascript part that relies on some errorlisteners being triggered could change behaviour. - With myfaces:queuesize set to 1 it's hard to think of an application that would change behaviour. Maybe a button that increases a counter by 1 (or scrolls a list by 1 page) on each click would miss some of the clicks if the user has a quick thumb. I cannot think of a szenario where myfaces:queuesize=1 would make an application run into errors (can you?). I think all 3 of these are special cases where minor changes of behaviour occur, none of them fundamentally changes the behaviour of the app. Best Regards, Ganesh Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Then just document t:ajax is an extension that's not compatible with RI. On Thu, Apr 23, 2009 at 5:39 PM, Ganesh gan...@j4fry.org wrote: Hi, The options don't work with the RI, so t:ajax isn't feasable afaik. Best Regards, Ganesh Cagatay Civici schrieb: The legacy way myfaces followed for a long time is to have standards in core and extensions in tomahawk. Isn't it the whole idea of t:inputText, t:dataTable? So I'm -1 as well for that kind of extensions in core so t:ajax sounds fine. Cagatay On Thu, Apr 23, 2009 at 5:06 PM, Ganesh gan...@j4fry.org mailto: gan...@j4fry.org wrote: Hi, How would you get the options into tomahawk? They rely on the Javascript core and tomahawk needs to run with the RI. What is myfaces:ajax? Is it another namespace included with the core, containing only a single tag? It seems confusing for the users to have additional options available on jsf.ajax.request which cannot be triggered when using the declarative approach without adding an extensions jar. Best Regards, Ganesh Werner Punz schrieb: Sorry I have not read the original post here I agree with Simon in the regard, that we should not add the options thing to our standard f:ajax tag, but would go even further to add nothing to f:ajax at all which is outside of the spec! The reason for this is, it would break the behavior we have done in the past and people relied upon. Up until now we added extensions on tag level via our own tag(Partially enforced by the TCK) So -1 to adding anything custom to f:ajax +1 to enable the users to access our internal custom options with myfaces:ajax or t:ajax Sorry for my lengthy post before, which was semi off topic, I should had read the entire conversation before posting a reply. Werner Ganesh schrieb: Hi Simon, Avoiding any change of behaviour within myfaces special options doesn't seem adequate to me. EVERY myfaces option will change the behaviour. MyFaces 1.2 supports org.apache.myfaces.SERIALIZE_STATE_IN_SESSION With this option set some applications may add non serializable beans to the state, breaking compatibility with other implementations. It is obvious to the developer that options starting with myfaces can induce compatibility problems. Imho you hit the point when you said before that core extensions should be avoided if they do fundamentally change the behaviour of the app. Standard applications should be remain portable in spite of implementation options set. Here's a short discussion on the portability issues of the proposed extension options: - With myfaces:pps set to true applications that evaluate request parameters within phase 5 could change their behaviour. - With myfaces:errorlevel set to WARNING applications that have a Javascript part that relies on some errorlisteners being triggered could change behaviour. - With myfaces:queuesize set to 1 it's hard to think of an application that would change behaviour. Maybe a button that increases a counter by 1 (or scrolls a list by 1 page) on each click would miss some of the clicks if the user has a quick thumb. I cannot think of a szenario where myfaces:queuesize=1 would make an application run into errors (can you?). I think all 3 of these are special cases where minor changes of behaviour occur, none of them fundamentally changes the behaviour of the app. Best Regards, Ganesh Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created.
Re: f:ajax and MyFaces extensions
On Wed, Apr 22, 2009 at 7:54 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... +1 for a non facelet based solution... As I was thinking about this bit more. I think we are now there that JSP is officially (almost) dead. When you want to upgrade, by simple replacing the JARs, this will work. Moving forward in your project, by using the new introduced stuff, you have to use Facelets. So, I am +1 for what Ganesh proposed (= CORE) I am not against an tomahawk:ajax tag, for JSP, if one want's that. I am still -1 regarding a pure facelet based one, JSF is not dead, it is not smelling yet... no, but JSP Seriously most projects use facelets nowadays but I would not call JSP dead, but they EG decided to add new things (e.g. f:ajax) only to the facelets view. -M besides that the new component api simplifies things anyway, so it is not that hard to provide something on api level. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
On Wed, Apr 22, 2009 at 8:00 AM, Matthias Wessendorf mat...@apache.org wrote: On Wed, Apr 22, 2009 at 7:54 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... +1 for a non facelet based solution... As I was thinking about this bit more. I think we are now there that JSP is officially (almost) dead. When you want to upgrade, by simple replacing the JARs, this will work. Moving forward in your project, by using the new introduced stuff, you have to use Facelets. So, I am +1 for what Ganesh proposed (= CORE) I am not against an tomahawk:ajax tag, for JSP, if one want's that. I am still -1 regarding a pure facelet based one, JSF is not dead, it is not smelling yet... no, but JSP Seriously most projects use facelets nowadays but I would not call JSP dead, but they EG decided to add new things (e.g. f:ajax) only to the facelets view. I guess they did that b/c they think JSP is dead. Also, there is this time no new JSP version, next to a new Servlet version. That is also a sign that JSP is not more that (well) alive Anyway, Tomahawk can ship an :ajax tag. Or something like the previous discussed myfaces:ajax as well. But for Facelets I like Ganesh's proposal -M -M besides that the new component api simplifies things anyway, so it is not that hard to provide something on api level. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Matthias Wessendorf schrieb: On Wed, Apr 22, 2009 at 7:54 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... +1 for a non facelet based solution... As I was thinking about this bit more. I think we are now there that JSP is officially (almost) dead. When you want to upgrade, by simple replacing the JARs, this will work. Moving forward in your project, by using the new introduced stuff, you have to use Facelets. So, I am +1 for what Ganesh proposed (= CORE) I am not against an tomahawk:ajax tag, for JSP, if one want's that. I am still -1 regarding a pure facelet based one, JSF is not dead, it is not smelling yet... no, but JSP Sorry I have not had my coffee yet, I meant JSP when I wrote JSF... Seriously most projects use facelets nowadays but I would not call JSP dead, but they EG decided to add new things (e.g. f:ajax) only to the facelets view. Yes I see that as problematic, I have to recheck the specs, I have not been to the component level yet, since all my work has been javascript mostly and a little bit of facesContext, if a pure facelets based renderer of a component can be used within jsp, I doubt it. Werner
Re: f:ajax and MyFaces extensions
Ok I did a quick look over the facelets section as it seems, it is facelets or jsp just like we had in the past... I would have loved to have a templating on the renderer side for jsp as well, oh well... Werner Werner Punz schrieb: Matthias Wessendorf schrieb: On Wed, Apr 22, 2009 at 7:54 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... +1 for a non facelet based solution... As I was thinking about this bit more. I think we are now there that JSP is officially (almost) dead. When you want to upgrade, by simple replacing the JARs, this will work. Moving forward in your project, by using the new introduced stuff, you have to use Facelets. So, I am +1 for what Ganesh proposed (= CORE) I am not against an tomahawk:ajax tag, for JSP, if one want's that. I am still -1 regarding a pure facelet based one, JSF is not dead, it is not smelling yet... no, but JSP Sorry I have not had my coffee yet, I meant JSP when I wrote JSF... Seriously most projects use facelets nowadays but I would not call JSP dead, but they EG decided to add new things (e.g. f:ajax) only to the facelets view. Yes I see that as problematic, I have to recheck the specs, I have not been to the component level yet, since all my work has been javascript mostly and a little bit of facesContext, if a pure facelets based renderer of a component can be used within jsp, I doubt it. Werner
Re: f:ajax and MyFaces extensions
On Wed, Apr 22, 2009 at 8:19 AM, Werner Punz werner.p...@gmail.com wrote: Ok I did a quick look over the facelets section as it seems, it is facelets or jsp just like we had in the past... but if I understood things right. New features (- f:ajax) only for facelets -Matthias I would have loved to have a templating on the renderer side for jsp as well, oh well... Werner Werner Punz schrieb: Matthias Wessendorf schrieb: On Wed, Apr 22, 2009 at 7:54 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... +1 for a non facelet based solution... As I was thinking about this bit more. I think we are now there that JSP is officially (almost) dead. When you want to upgrade, by simple replacing the JARs, this will work. Moving forward in your project, by using the new introduced stuff, you have to use Facelets. So, I am +1 for what Ganesh proposed (= CORE) I am not against an tomahawk:ajax tag, for JSP, if one want's that. I am still -1 regarding a pure facelet based one, JSF is not dead, it is not smelling yet... no, but JSP Sorry I have not had my coffee yet, I meant JSP when I wrote JSF... Seriously most projects use facelets nowadays but I would not call JSP dead, but they EG decided to add new things (e.g. f:ajax) only to the facelets view. Yes I see that as problematic, I have to recheck the specs, I have not been to the component level yet, since all my work has been javascript mostly and a little bit of facesContext, if a pure facelets based renderer of a component can be used within jsp, I doubt it. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Hi Werner, Does this mean Matthias succeeded in convincing you that f:ajax is facelets-only and can receive an additional attribute without breaking the TCK or the spec? Also, please see the spec, section 10.1: New features introduced in version 2 and later are only exposed to page authors using Facelets. JSP is retained for backwards compatibility. Imho, this is the polite way of saying JSP is dead. Best Regards, Ganesh Werner Punz schrieb: Ok I did a quick look over the facelets section as it seems, it is facelets or jsp just like we had in the past... I would have loved to have a templating on the renderer side for jsp as well, oh well... Werner
Re: f:ajax and MyFaces extensions
On Wed, Apr 22, 2009 at 9:16 AM, Ganesh gan...@j4fry.org wrote: Hi Werner, Does this mean Matthias succeeded in convincing you that f:ajax is facelets-only and can receive an additional attribute without breaking the TCK or the spec? Also, please see the spec, section 10.1: New features introduced in version 2 and later are only exposed to page authors using Facelets. JSP is retained for backwards compatibility. thanks for pointing out the exact section in the spec. Imho, this is the polite way of saying JSP is dead. :-) that would be honest as well Best Regards, Ganesh Werner Punz schrieb: Ok I did a quick look over the facelets section as it seems, it is facelets or jsp just like we had in the past... I would have loved to have a templating on the renderer side for jsp as well, oh well... Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Werner Punz schrieb: Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... yeah. I know. I am really wondering why the support all views ship sailed away. Again, I understand that some solutions may only fly in Facelets land... That said, but wasn't the promised goal of the formal/current EG that a flexible ViewLayer was the KEY ? == Swing-based RenderKit etc ? Or is this (JSF) just another web-framework ? Well the entire ajax part makes only sense in the web domain. f:ajax definitely is not suitable for swing and others. Why doesn't partial-page-updating make sense for presentation layers other than HTML? If a JSF renderkit was to generate some special markup that a client app (browser replacement) then created swing components from, that submitting part of the page (a subset of the swing widgets) would still be a useful thing to do, wouldn't it? Is the JSF2.0 PPR-related spec designed to handle this, ie is the response message structured so that a non-browser can still interpret it correctly? As long as the response contains just XML with component ids and values, it seems that this would work ok... Cheers, Simon
Re: f:ajax and MyFaces extensions
Hi, Unlike JSP tags, facelet tags do not declare or validate attributes (ie you can define any attributes you like on a facelet tag without getting a this attribute does not exist error) [1], so the TCK presumably would not be able to detect whether MyFaces has extended the spec with custom attributes. However my personal opinion is that adding custom behaviour to a standard tag is *wrong* if the app would fail to work correctly when the attributes are ignored. In other words, adding optimisation or debugging-helper params is acceptable, but otherwise not. Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created. [1] At least, facelets for JSF1.2 works this way. I presume this hasn't changed... Regards, Simon Ganesh schrieb: Hi Werner, Does this mean Matthias succeeded in convincing you that f:ajax is facelets-only and can receive an additional attribute without breaking the TCK or the spec? Also, please see the spec, section 10.1: New features introduced in version 2 and later are only exposed to page authors using Facelets. JSP is retained for backwards compatibility. Imho, this is the polite way of saying JSP is dead. Best Regards, Ganesh Werner Punz schrieb: Ok I did a quick look over the facelets section as it seems, it is facelets or jsp just like we had in the past... I would have loved to have a templating on the renderer side for jsp as well, oh well... Werner
Re: f:ajax and MyFaces extensions
Simon Kitching schrieb: tely is not suitable for swing and others. Why doesn't partial-page-updating make sense for presentation layers other than HTML? Because the way it is defined makes only sense in html... Other presentation layers can do something similar but they have to go their own way... I will give an example: The spec say, ppr has to be done by encoding the values of the form elements and send them asynchrously and queued to the server. That is sort of general but still very http centric... The real html specifics come in the response, where there are clearly references to html body and head tags... The way I see it is that html makes such things extra hard, in swing implementing a ppr probably would be a ten lines of code, you dont have to deal with browser specifics, dom, and xhr nastyness but you can use sockets and a real isolated component model... So f:ajax to me makes really only sense in a html domain, other domains which can support similar mechanisms have better alternatives to deal with this! (Real sockets, isolated component models, better communcation layers like rmi or corba, real threads instead of an xhr hack) Werner
Re: f:ajax and MyFaces extensions
Simon Kitching schrieb: Hi, Unlike JSP tags, facelet tags do not declare or validate attributes (ie you can define any attributes you like on a facelet tag without getting a this attribute does not exist error) [1], so the TCK presumably would not be able to detect whether MyFaces has extended the spec with custom attributes. However my personal opinion is that adding custom behaviour to a standard tag is *wrong* if the app would fail to work correctly when the attributes are ignored. In other words, adding optimisation or debugging-helper params is acceptable, but otherwise not. Adding behaviour-changing features to standard tags is setting a portability trap for users, where their app will silently fail to run correctly when executed on a different JSF implementation. That seems unacceptable to me, even if the TCK cannot technically detect it. So for the two params you are proposing which are just performance tweaks, just attributes on f:ajax, or using nested f:attribute seems ok. But for the other one (queueLength?) I would strongly recommend an mf:ajax or mf:attribute tag be created. [1] At least, facelets for JSF1.2 works this way. I presume this hasn't changed... To my knowledge they did add something on the behavioral side of facelets it is a sort of backward compatible but extended new version. But I can be wrong, I am not an expert on the facelets integration in jsf2... Werner
Re: f:ajax and MyFaces extensions
Hi Matthias, Simon (K.) and Werner, Sorry I need to come back on this again. We had agreed on putting the extension attributes within f:attribute tags nested in f:ajax to avoid compatibility issues with other implementations. In the meantime I realized that f:ajax is a facelets-only tag, so additional tag attributes aren't declared in a taglib, would be ignored by other implementations and cannot be detected by the TCK. So, I changed my mind and now would prefer f:ajax myfaces=pps:true, queuesize:1/ over f:ajax f:attribute name=myfaces_pps value=true/ f:attribute name=myfaces_queuesize value=1/ /f:ajax because the former is less verbose and better readable. Can you agree with these new arguments? Best Regards, Ganesh
Re: f:ajax and MyFaces extensions
On Tue, Apr 21, 2009 at 6:42 PM, Ganesh gan...@j4fry.org wrote: Hi Matthias, Simon (K.) and Werner, no need to name only a few folks. Choosing the right subject will bring attention to folks that are interested ;-) Sorry I need to come back on this again. We had agreed on putting the extension attributes within f:attribute tags nested in f:ajax to avoid compatibility issues with other implementations. In the meantime I realized that f:ajax is a facelets-only tag, so additional tag attributes aren't :-) it is funny that the core statement was every view needs to be supported. I can see that some features may only work with Facelets, but a Tag should be present for both, JSP(X) and Facelets. Or am I wrong ? declared in a taglib, would be ignored by other implementations and cannot be detected by the TCK. So, I changed my mind and now would prefer f:ajax myfaces=pps:true, queuesize:1/ I like that. over f:ajax f:attribute name=myfaces_pps value=true/ f:attribute name=myfaces_queuesize value=1/ /f:ajax because the former is less verbose and better readable. +1 I am with you -M Can you agree with these new arguments? Best Regards, Ganesh -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Well then we have to go for a custom tag, we cannot put the myfaces attribute into f:ajax, due to TCK restrictions, we probably have to roll an additonal myfaces:ajax tag! I have no objections to that, since we add a load of optional enhancements to the javascript core anyway, so adding an additional tag under the myfaces or tomahawk umbrella is a non issue to me. Werner Ganesh schrieb: Hi Matthias, Simon (K.) and Werner, Sorry I need to come back on this again. We had agreed on putting the extension attributes within f:attribute tags nested in f:ajax to avoid compatibility issues with other implementations. In the meantime I realized that f:ajax is a facelets-only tag, so additional tag attributes aren't declared in a taglib, would be ignored by other implementations and cannot be detected by the TCK. So, I changed my mind and now would prefer f:ajax myfaces=pps:true, queuesize:1/ over f:ajax f:attribute name=myfaces_pps value=true/ f:attribute name=myfaces_queuesize value=1/ /f:ajax because the former is less verbose and better readable. Can you agree with these new arguments? Best Regards, Ganesh
Re: f:ajax and MyFaces extensions
On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... yeah. I know. I am really wondering why the support all views ship sailed away. Again, I understand that some solutions may only fly in Facelets land... That said, but wasn't the promised goal of the formal/current EG that a flexible ViewLayer was the KEY ? == Swing-based RenderKit etc ? Or is this (JSF) just another web-framework ? +1 for a non facelet based solution... Werner Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 6:42 PM, Ganesh gan...@j4fry.org wrote: Hi Matthias, Simon (K.) and Werner, no need to name only a few folks. Choosing the right subject will bring attention to folks that are interested ;-) Sorry I need to come back on this again. We had agreed on putting the extension attributes within f:attribute tags nested in f:ajax to avoid compatibility issues with other implementations. In the meantime I realized that f:ajax is a facelets-only tag, so additional tag attributes aren't :-) it is funny that the core statement was every view needs to be supported. I can see that some features may only work with Facelets, but a Tag should be present for both, JSP(X) and Facelets. Or am I wrong ? declared in a taglib, would be ignored by other implementations and cannot be detected by the TCK. So, I changed my mind and now would prefer f:ajax myfaces=pps:true, queuesize:1/ I like that. over f:ajax f:attribute name=myfaces_pps value=true/ f:attribute name=myfaces_queuesize value=1/ /f:ajax because the former is less verbose and better readable. +1 I am with you -M Can you agree with these new arguments? Best Regards, Ganesh -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
On Wed, Apr 22, 2009 at 12:09 AM, Matthias Wessendorf mat...@apache.org wrote: On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... yeah. I know. I am really wondering why the support all views ship sailed away. Again, I understand that some solutions may only fly in Facelets land... Thinking a bit about this, ...yeah, JSP is dead :-) simple migration (just updating the JARs) to JSF 2.0 will work. Using new features = have to use Facelets That said, but wasn't the promised goal of the formal/current EG that a flexible ViewLayer was the KEY ? == Swing-based RenderKit etc ? Or is this (JSF) just another web-framework ? Doing an f:ajax for JSP shouldn't be hard. An extension could do that. So, yeah, we were always saying JSP is dead. Now it is almost official :-) Not sure if that is really communicated that way. +1 for a non facelet based solution... Werner Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 6:42 PM, Ganesh gan...@j4fry.org wrote: Hi Matthias, Simon (K.) and Werner, no need to name only a few folks. Choosing the right subject will bring attention to folks that are interested ;-) Sorry I need to come back on this again. We had agreed on putting the extension attributes within f:attribute tags nested in f:ajax to avoid compatibility issues with other implementations. In the meantime I realized that f:ajax is a facelets-only tag, so additional tag attributes aren't :-) it is funny that the core statement was every view needs to be supported. I can see that some features may only work with Facelets, but a Tag should be present for both, JSP(X) and Facelets. Or am I wrong ? declared in a taglib, would be ignored by other implementations and cannot be detected by the TCK. So, I changed my mind and now would prefer f:ajax myfaces=pps:true, queuesize:1/ I like that. over f:ajax f:attribute name=myfaces_pps value=true/ f:attribute name=myfaces_queuesize value=1/ /f:ajax because the former is less verbose and better readable. +1 I am with you -M Can you agree with these new arguments? Best Regards, Ganesh -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz werner.p...@gmail.com wrote: Actually We probably can provide a non facelets based solution under the myfaces umbrella, tomahawk, extensions or impl I don´t care but I am definitely sure we will be unable to provide it under the standard f: tags... +1 for a non facelet based solution... As I was thinking about this bit more. I think we are now there that JSP is officially (almost) dead. When you want to upgrade, by simple replacing the JARs, this will work. Moving forward in your project, by using the new introduced stuff, you have to use Facelets. So, I am +1 for what Ganesh proposed (= CORE) I am not against an tomahawk:ajax tag, for JSP, if one want's that. -Matthias Werner Matthias Wessendorf schrieb: On Tue, Apr 21, 2009 at 6:42 PM, Ganesh gan...@j4fry.org wrote: Hi Matthias, Simon (K.) and Werner, no need to name only a few folks. Choosing the right subject will bring attention to folks that are interested ;-) Sorry I need to come back on this again. We had agreed on putting the extension attributes within f:attribute tags nested in f:ajax to avoid compatibility issues with other implementations. In the meantime I realized that f:ajax is a facelets-only tag, so additional tag attributes aren't :-) it is funny that the core statement was every view needs to be supported. I can see that some features may only work with Facelets, but a Tag should be present for both, JSP(X) and Facelets. Or am I wrong ? declared in a taglib, would be ignored by other implementations and cannot be detected by the TCK. So, I changed my mind and now would prefer f:ajax myfaces=pps:true, queuesize:1/ I like that. over f:ajax f:attribute name=myfaces_pps value=true/ f:attribute name=myfaces_queuesize value=1/ /f:ajax because the former is less verbose and better readable. +1 I am with you -M Can you agree with these new arguments? Best Regards, Ganesh -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Hi, unfortunately the behavior changes if you use the parameters (especially the queue-size). The parameters pps and errorlevel don't change the behavior. For me pps is a performance enhancement because it doens't make sense to pass all the elemenents on the page when they are not mentioned in the execute-parameter. Maybe we don't need the errorlevel extension because the spec. says errorhandling is controlled by project stage (see 13.3.6.3 in the spec.) The queue-size is very interesting. In many cases the last user interaction is relevant. So a one-element-queue-size would be ok but Werner had some examples where a larger queue-size is necessary. So +1 for the f:attributes solution :-) 2009/4/17 Simon Kitching skitch...@apache.org Matthias Wessendorf schrieb: On Fri, Apr 17, 2009 at 2:24 PM, Ganesh gan...@j4fry.org wrote: As Simon said, inclusion into f:ajax is probably not a good idea, because applications using JSP+Mojarra would break when containing the additional param. Just FYI, myfaces core *must* pass the Sun TCK (compatibility test kit) in order to call itself JSF at all. And the TCK specifically checks for non-standard attributes on any standard tags/classes. So adding any non-standard attributes to standard tags (eg adding stuff to f:ajax) simply cannot be done; the TCK will fail. Sun's intention is to specifically catch cases where a vendor has non-standard extensions that make pages non-portable to other implementations - like when Microsoft tried to extend Java with windows-only features. And this is a good thing IMO. Non-portable extensions have to go into separate libs instead. From your description of the new flags, it sounds like a page will fall back gracefully when run on other containers (slightly noisier with JSF error messages, slightly more data posted on each submit, but still working) so nesting f:attributes seems fair in this case. One thing to check would be that the f:ajax tag isn't marked as empty in the DTD/schema, ie that f:attribute tags can be nested inside it. Cheers, Simon -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: f:ajax and MyFaces extensions
Alexander Bell schrieb: Hi, unfortunately the behavior changes if you use the parameters (especially the queue-size). The parameters pps and errorlevel don't change the behavior. For me pps is a performance enhancement because it doens't make sense to pass all the elemenents on the page when they are not mentioned in the execute-parameter. Maybe we don't need the errorlevel extension because the spec. says errorhandling is controlled by project stage (see 13.3.6.3 in the spec.) Yes, afair this part says that errors on development stage must trigger alerts, I probably would extend that with a config param to trigger console debugs instead, the defaults however should be errors! Btw. another thing regarding the configuration, the way I see it we need two kinds of configurations, a static per page configuration which keeps things like binding the layers (which to some extent already is done to bind api and impl for instance) which could be extended with things like a log handler (alert per default) for instance and a dynamic configuration on a per request base which we currently have under options.myfaces like turn off full form post for performance reasons... The queue size handling for instance makes sense on a per page base while a load of others make sense on a dynamic base... Werner The queue-size is very interesting. In many cases the last user interaction is relevant. So a one-element-queue-size would be ok but Werner had some examples where a larger queue-size is necessary.
Re: f:ajax and MyFaces extensions
On Fri, Apr 17, 2009 at 12:41 PM, Ganesh gan...@j4fry.org wrote:
Hi,
Here's a question concerning the extension parameters pps, queuesize and
errorlevel in conjunction with the f:ajax tag. They form part of the
Javascript xhrCore and can be set via jsf.ajax.request(this, event,
{execute:'xxx', render:'yyy', myfaces:{pps:true, queuesize:1, errorlevel:
'error'}}).
For the ajax tag the extension parameters could reside in an attribute
myfaces: myfaces={pps:true, queuesize:1, errorlevel: 'error'}.
Now, should this extension parameter become part of the f:ajax tag or should
mf:ajax ?
By that one could use this core extension, when using myfaces lib.
we build a t:ajax tomahawk tag?
-1 this would tie the use really to tomahawk;
Why not doing a mf:ajax which is a taglib that sits inside the myfaces-impl.jar
-M
Please give your comment on this!
Best Regards,
Ganesh Jung
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 12:41 PM, Ganesh gan...@j4fry.org wrote:
Hi,
Here's a question concerning the extension parameters pps, queuesize and
errorlevel in conjunction with the f:ajax tag. They form part of the
Javascript xhrCore and can be set via jsf.ajax.request(this, event,
{execute:'xxx', render:'yyy', myfaces:{pps:true, queuesize:1, errorlevel:
'error'}}).
For the ajax tag the extension parameters could reside in an attribute
myfaces: myfaces={pps:true, queuesize:1, errorlevel: 'error'}.
Now, should this extension parameter become part of the f:ajax tag or should
mf:ajax ?
By that one could use this core extension, when using myfaces lib.
we build a t:ajax tomahawk tag?
-1 this would tie the use really to tomahawk;
Why not doing a mf:ajax which is a taglib that sits inside the
myfaces-impl.jar
But then any web page that uses this mf:ajax tag would not work when run
on a different container (eg mojarra), as that tag would not exist.
The tomahawk tag sounds better to me. If I understand correctly, a page
using it would still work on other containers as long as tomahawk was in
the classpath. The extra params to jsf.ajax.request would be rendered
into the page, and sent back to the container, but then not used.
Possibly nested attributes could be used?
f:ajax ...
f:attribute name=myfaces:pps value=true/
f:attribute name=myfaces:queuesize value=1/
/f:ajax
When a page containing that tag is used in a container that doesn't
recognise these attributes, I expect they would just be ignored (the
extra attributes would not be rendered into the generated page).
Regards,
Simon
Re: f:ajax and MyFaces extensions
On Fri, Apr 17, 2009 at 1:12 PM, Simon Kitching skitch...@apache.org wrote:
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 12:41 PM, Ganesh gan...@j4fry.org wrote:
Hi,
Here's a question concerning the extension parameters pps, queuesize and
errorlevel in conjunction with the f:ajax tag. They form part of the
Javascript xhrCore and can be set via jsf.ajax.request(this, event,
{execute:'xxx', render:'yyy', myfaces:{pps:true, queuesize:1, errorlevel:
'error'}}).
For the ajax tag the extension parameters could reside in an attribute
myfaces: myfaces={pps:true, queuesize:1, errorlevel: 'error'}.
Now, should this extension parameter become part of the f:ajax tag or should
mf:ajax ?
By that one could use this core extension, when using myfaces lib.
we build a t:ajax tomahawk tag?
-1 this would tie the use really to tomahawk;
Why not doing a mf:ajax which is a taglib that sits inside the
myfaces-impl.jar
But then any web page that uses this mf:ajax tag would not work when run
on a different container (eg mojarra), as that tag would not exist.
correct.
same would be the case (even worse) if the behavior of f:ajax (silly name btw)
is different than expected.
The tomahawk tag sounds better to me. If I understand correctly, a page
isn't that big ? including tons of components, extras etc just because of that ?
Or, an myfaces-extension lib ? (good old times... :-) )
-M
using it would still work on other containers as long as tomahawk was in
the classpath. The extra params to jsf.ajax.request would be rendered
into the page, and sent back to the container, but then not used.
Possibly nested attributes could be used?
f:ajax ...
f:attribute name=myfaces:pps value=true/
f:attribute name=myfaces:queuesize value=1/
/f:ajax
When a page containing that tag is used in a container that doesn't
recognise these attributes, I expect they would just be ignored (the
extra attributes would not be rendered into the generated page).
Regards,
Simon
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 1:12 PM, Simon Kitching skitch...@apache.org wrote:
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 12:41 PM, Ganesh gan...@j4fry.org wrote:
Hi,
Here's a question concerning the extension parameters pps, queuesize and
errorlevel in conjunction with the f:ajax tag. They form part of the
Javascript xhrCore and can be set via jsf.ajax.request(this, event,
{execute:'xxx', render:'yyy', myfaces:{pps:true, queuesize:1, errorlevel:
'error'}}).
For the ajax tag the extension parameters could reside in an attribute
myfaces: myfaces={pps:true, queuesize:1, errorlevel: 'error'}.
Now, should this extension parameter become part of the f:ajax tag or
should
mf:ajax ?
By that one could use this core extension, when using myfaces lib.
we build a t:ajax tomahawk tag?
-1 this would tie the use really to tomahawk;
Why not doing a mf:ajax which is a taglib that sits inside the
myfaces-impl.jar
But then any web page that uses this mf:ajax tag would not work when run
on a different container (eg mojarra), as that tag would not exist.
correct.
same would be the case (even worse) if the behavior of f:ajax (silly name btw)
is different than expected.
Well, I guess it depends on what these pps/queuesize/errorlevel params
do. They looked to me like optimisation tweaks, ie if they weren't
there then the page would still work.
But if they do fundamentally change the behaviour of the app (ie the app
won't work as expected if they are ignored) then I would agree that your
suggested mf:ajax tag would be better than nested f:attribute tags.
Possibly nested attributes could be used?
f:ajax ...
f:attribute name=myfaces:pps value=true/
f:attribute name=myfaces:queuesize value=1/
/f:ajax
The tomahawk tag sounds better to me. If I understand correctly, a page
isn't that big ? including tons of components, extras etc just because of
that ?
Or, an myfaces-extension lib ? (good old times... :-) )
Yes, I guess a myfaces-extension lib would be better (smaller) than
tomahawk. It didn't occur to me because I have never used one (has anyone?).
Regards,
Simon
Re: f:ajax and MyFaces extensions
Hi Matthias and Simon, Thank you for taking time do discuss to proper way to include the myfaces params into the ajax tag. To clarify things, here is what they do: pps (true/false): Only the components named in the execute parameter will be processed in phase 2-4, but the spec insists on submitting all elements included in a form. If pps is set to true submission is reduced to the form params named in execute. queuesize: The spec specifies an unlimited ajax queue, though for most usages a queue size of 1 is appropriate. This param makes the queue size configurable. errorlevel: Javascript errors occuring during ajax execution would by default be suppressed, but with higher levels they would be signaled. As Simon said, inclusion into f:ajax is probably not a good idea, because applications using JSP+Mojarra would break when containing the additional param. On the other hand I agree with Matthias that t:ajax would tie the use to tomahawk. I really like Simons proposal for f:attributes nested inside f:ajax, +1 on this one! Best Regards, Ganesh
Re: f:ajax and MyFaces extensions
On Fri, Apr 17, 2009 at 2:24 PM, Ganesh gan...@j4fry.org wrote: Hi Matthias and Simon, Thank you for taking time do discuss to proper way to include the myfaces params into the ajax tag. To clarify things, here is what they do: pps (true/false): Only the components named in the execute parameter will be processed in phase 2-4, but the spec insists on submitting all elements included in a form. If pps is set to true submission is reduced to the form params named in execute. queuesize: The spec specifies an unlimited ajax queue, though for most usages a queue size of 1 is appropriate. This param makes the queue size configurable. errorlevel: Javascript errors occuring during ajax execution would by default be suppressed, but with higher levels they would be signaled. As Simon said, inclusion into f:ajax is probably not a good idea, because applications using JSP+Mojarra would break when containing the additional param. On the other hand I agree with Matthias that t:ajax would tie the use to tomahawk. I really like Simons proposal for f:attributes nested inside f:ajax, +1 on this one! same here. I thought it would change the behavior, hence I was against f:ajax. The attrs is fine w/ me -M Best Regards, Ganesh -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
On Fri, Apr 17, 2009 at 1:35 PM, Simon Kitching skitch...@apache.org wrote:
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 1:12 PM, Simon Kitching skitch...@apache.org wrote:
Matthias Wessendorf schrieb:
On Fri, Apr 17, 2009 at 12:41 PM, Ganesh gan...@j4fry.org wrote:
Hi,
Here's a question concerning the extension parameters pps, queuesize and
errorlevel in conjunction with the f:ajax tag. They form part of the
Javascript xhrCore and can be set via jsf.ajax.request(this, event,
{execute:'xxx', render:'yyy', myfaces:{pps:true, queuesize:1, errorlevel:
'error'}}).
For the ajax tag the extension parameters could reside in an attribute
myfaces: myfaces={pps:true, queuesize:1, errorlevel: 'error'}.
Now, should this extension parameter become part of the f:ajax tag or
should
mf:ajax ?
By that one could use this core extension, when using myfaces lib.
we build a t:ajax tomahawk tag?
-1 this would tie the use really to tomahawk;
Why not doing a mf:ajax which is a taglib that sits inside the
myfaces-impl.jar
But then any web page that uses this mf:ajax tag would not work when run
on a different container (eg mojarra), as that tag would not exist.
correct.
same would be the case (even worse) if the behavior of f:ajax (silly name
btw)
is different than expected.
Well, I guess it depends on what these pps/queuesize/errorlevel params
do. They looked to me like optimisation tweaks, ie if they weren't
there then the page would still work.
But if they do fundamentally change the behaviour of the app (ie the app
won't work as expected if they are ignored) then I would agree that your
suggested mf:ajax tag would be better than nested f:attribute tags.
at least I understood it that way, if not the attribute makes sense, yes
Possibly nested attributes could be used?
f:ajax ...
f:attribute name=myfaces:pps value=true/
f:attribute name=myfaces:queuesize value=1/
/f:ajax
The tomahawk tag sounds better to me. If I understand correctly, a page
isn't that big ? including tons of components, extras etc just because of
that ?
Or, an myfaces-extension lib ? (good old times... :-) )
Yes, I guess a myfaces-extension lib would be better (smaller) than
tomahawk. It didn't occur to me because I have never used one (has anyone?).
yes
Regards,
Simon
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: f:ajax and MyFaces extensions
Matthias Wessendorf schrieb: On Fri, Apr 17, 2009 at 2:24 PM, Ganesh gan...@j4fry.org wrote: As Simon said, inclusion into f:ajax is probably not a good idea, because applications using JSP+Mojarra would break when containing the additional param. Just FYI, myfaces core *must* pass the Sun TCK (compatibility test kit) in order to call itself JSF at all. And the TCK specifically checks for non-standard attributes on any standard tags/classes. So adding any non-standard attributes to standard tags (eg adding stuff to f:ajax) simply cannot be done; the TCK will fail. Sun's intention is to specifically catch cases where a vendor has non-standard extensions that make pages non-portable to other implementations - like when Microsoft tried to extend Java with windows-only features. And this is a good thing IMO. Non-portable extensions have to go into separate libs instead. From your description of the new flags, it sounds like a page will fall back gracefully when run on other containers (slightly noisier with JSF error messages, slightly more data posted on each submit, but still working) so nesting f:attributes seems fair in this case. One thing to check would be that the f:ajax tag isn't marked as empty in the DTD/schema, ie that f:attribute tags can be nested inside it. Cheers, Simon
