You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Ganesh <ga...@j4fry.org> on 2009/04/17 12:41:33 UTC
f:ajax and MyFaces extensions
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 we build a t:ajax tomahawk tag? Please give your comment on this!
Best Regards,
Ganesh Jung
Re: f:ajax and MyFaces extensions
Posted by Werner Punz <we...@gmail.com>.
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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Wed, Apr 22, 2009 at 12:09 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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 <ga...@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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Wed, Apr 22, 2009 at 8:00 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> On Wed, Apr 22, 2009 at 7:54 AM, Werner Punz <we...@gmail.com> wrote:
>> Matthias Wessendorf schrieb:
>>>
>>> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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: [VOTE] MyFaces 2.0 optimization options
Posted by Simon Lessard <si...@gmail.com>.
[1] +1
[2] -1
[3] -1
[4] +0
On Fri, Apr 24, 2009 at 9:40 AM, Cagatay Civici <ca...@gmail.com>wrote:
> [1] +1
> [2] -1
> [3] -1
> [4] +0
>
>
> On Fri, Apr 24, 2009 at 2:32 PM, Werner Punz <we...@gmail.com>wrote:
>
>>
>> [1] +1
>> [2] -1
>> [3] -1
>> [4] +1
>>
>> Werner
>>
>>
>>
>> Ganesh schrieb:
>>
>> Hi,
>>>
>>> We are trying to agree on a way to include the optimization options
>>> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
>>> Javascript with the MyFaces JSF 2.0 implementation.
>>>
>>> We've got 4 different proposed solutions, each has been checked for
>>> technical feasability:
>>>
>>> 1.) extra options packed in a new t:ajax tag 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
>>>
>>> Please consider the solutions and vote! See previous mails on this list
>>> with "f:ajax and MyFaces extensions" in the subject for further details.
>>>
>>> Please note:
>>> This vote is "majority approval" with a minimum of three +1 votes. This
>>> is a code modification vote [1], so you can veto a solution with a vote of
>>> -1. Please vote whole numbers. You can give a vote on each of the 4
>>> solutions. E.g. you can vote:
>>>
>>> 1.) +1
>>> 2.) +1
>>> 3.) +0
>>> 4.) -1
>>>
>>> The vote lasts for 72 hours. It start on 2009-04-24 11:45 a.m. and ends
>>> on 2009-04-27 11:45 a.m.
>>>
>>> ------------------------------------------------
>>> [ ] +1 - you favourize this solution
>>> [ ] +0 - you don't like this solution
>>> [ ] -1 - you veto this solution
>>>
>>>
>>> Best Regards,
>>> Ganesh Jung
>>>
>>> [1] http://www.apache.org/foundation/voting.html <
>>> http://www.apache.org/foundation/voting.html#ReleaseVotes>
>>>
>>>
>>
>
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Apr 27, 2009 at 5:36 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> Unfortunately, I don't have any knowledge about the ajax work you are
> all doing. However, I am -1 on anything that tries to intentionally
> break spec compatibility, such as reusing the f: namespace. Even if
> it's not explicitly spelled out, we know that it's against the spirit
> of the spec. I find it impossible to believe that there are not
> better approaches. And the reality is that the actual tags used in
> the namespace are under the control of the user anyway. If someone
> wanted to map mfx: as f:, it's trivial to do so in both jsp and in
JSP is dead. All the new JSF 2.0 features don't work with JSP
(unless one goes ahead and provides an extension for that,
e.g an t:ajax handler for JSP)
-Matthias
> facelets. But why would we encourage that behavior?
>
>
> On Mon, Apr 27, 2009 at 9:25 AM, Matthias Wessendorf <ma...@apache.org> wrote:
>> ok, let's start with t:ajax
>>
>> We can always add a new JAR, for mfx:ajax...
>> But to get this started, I am fine with the following:
>>
>> 1.) +1
>> 2.) +1
>> 3.) -0
>> 4.) +1 (I will do that some when later)
>>
>> I think this now we have some kinda agreement, right ?
>>
>> On Mon, Apr 27, 2009 at 3:20 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>>> On Mon, Apr 27, 2009 at 3:17 PM, Ganesh <ga...@j4fry.org> wrote:
>>>> Hi,
>>>>
>>>> The mf:ajax solution is the only one that completely breaks compatibility
>>>> with Mojarra. Applications using mf:ajax would simply fails on Mojarra. None
>>>
>>> not when that is an extra JAR, that is just shipped with the myfaces
>>> core release.
>>>
>>> -M
>>>
>>>> of solutions [1] to [3] would do so. Alex and me don't have a binding vote,
>>>> but it'll be us implementing this and we are both -1 on mf:ajax.
>>>>
>>>> mf:ajax is also worse than t:ajax because it doesn't bring myfaces
>>>> Javascript to Mojarra users. The Mojarra Javascript needs a lot of
>>>> improvement...
>>>>
>>>> Best Regards,
>>>> Ganesh
>>>>>
>>>>> -1 b/c that adds an odd dependency to tomahawk...
>>>>> mfx:xyz does make sense to be the home for myfaces core "improvements".
>>>>>
>>>>> -M
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Mike Kienenberger <mk...@gmail.com>.
Unfortunately, I don't have any knowledge about the ajax work you are
all doing. However, I am -1 on anything that tries to intentionally
break spec compatibility, such as reusing the f: namespace. Even if
it's not explicitly spelled out, we know that it's against the spirit
of the spec. I find it impossible to believe that there are not
better approaches. And the reality is that the actual tags used in
the namespace are under the control of the user anyway. If someone
wanted to map mfx: as f:, it's trivial to do so in both jsp and in
facelets. But why would we encourage that behavior?
On Mon, Apr 27, 2009 at 9:25 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> ok, let's start with t:ajax
>
> We can always add a new JAR, for mfx:ajax...
> But to get this started, I am fine with the following:
>
> 1.) +1
> 2.) +1
> 3.) -0
> 4.) +1 (I will do that some when later)
>
> I think this now we have some kinda agreement, right ?
>
> On Mon, Apr 27, 2009 at 3:20 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>> On Mon, Apr 27, 2009 at 3:17 PM, Ganesh <ga...@j4fry.org> wrote:
>>> Hi,
>>>
>>> The mf:ajax solution is the only one that completely breaks compatibility
>>> with Mojarra. Applications using mf:ajax would simply fails on Mojarra. None
>>
>> not when that is an extra JAR, that is just shipped with the myfaces
>> core release.
>>
>> -M
>>
>>> of solutions [1] to [3] would do so. Alex and me don't have a binding vote,
>>> but it'll be us implementing this and we are both -1 on mf:ajax.
>>>
>>> mf:ajax is also worse than t:ajax because it doesn't bring myfaces
>>> Javascript to Mojarra users. The Mojarra Javascript needs a lot of
>>> improvement...
>>>
>>> Best Regards,
>>> Ganesh
>>>>
>>>> -1 b/c that adds an odd dependency to tomahawk...
>>>> mfx:xyz does make sense to be the home for myfaces core "improvements".
>>>>
>>>> -M
>>>>
>>>
>>
>>
>>
>> --
>> 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: [VOTE] MyFaces 2.0 optimization options
Posted by Matthias Wessendorf <ma...@apache.org>.
ok, let's start with t:ajax
We can always add a new JAR, for mfx:ajax...
But to get this started, I am fine with the following:
1.) +1
2.) +1
3.) -0
4.) +1 (I will do that some when later)
I think this now we have some kinda agreement, right ?
On Mon, Apr 27, 2009 at 3:20 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> On Mon, Apr 27, 2009 at 3:17 PM, Ganesh <ga...@j4fry.org> wrote:
>> Hi,
>>
>> The mf:ajax solution is the only one that completely breaks compatibility
>> with Mojarra. Applications using mf:ajax would simply fails on Mojarra. None
>
> not when that is an extra JAR, that is just shipped with the myfaces
> core release.
>
> -M
>
>> of solutions [1] to [3] would do so. Alex and me don't have a binding vote,
>> but it'll be us implementing this and we are both -1 on mf:ajax.
>>
>> mf:ajax is also worse than t:ajax because it doesn't bring myfaces
>> Javascript to Mojarra users. The Mojarra Javascript needs a lot of
>> improvement...
>>
>> Best Regards,
>> Ganesh
>>>
>>> -1 b/c that adds an odd dependency to tomahawk...
>>> mfx:xyz does make sense to be the home for myfaces core "improvements".
>>>
>>> -M
>>>
>>
>
>
>
> --
> 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: [VOTE] MyFaces 2.0 optimization options
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Apr 27, 2009 at 3:17 PM, Ganesh <ga...@j4fry.org> wrote:
> Hi,
>
> The mf:ajax solution is the only one that completely breaks compatibility
> with Mojarra. Applications using mf:ajax would simply fails on Mojarra. None
not when that is an extra JAR, that is just shipped with the myfaces
core release.
-M
> of solutions [1] to [3] would do so. Alex and me don't have a binding vote,
> but it'll be us implementing this and we are both -1 on mf:ajax.
>
> mf:ajax is also worse than t:ajax because it doesn't bring myfaces
> Javascript to Mojarra users. The Mojarra Javascript needs a lot of
> improvement...
>
> Best Regards,
> Ganesh
>>
>> -1 b/c that adds an odd dependency to tomahawk...
>> mfx:xyz does make sense to be the home for myfaces core "improvements".
>>
>> -M
>>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Ganesh <ga...@j4fry.org>.
Hi,
The mf:ajax solution is the only one that completely breaks
compatibility with Mojarra. Applications using mf:ajax would simply
fails on Mojarra. None of solutions [1] to [3] would do so. Alex and me
don't have a binding vote, but it'll be us implementing this and we are
both -1 on mf:ajax.
mf:ajax is also worse than t:ajax because it doesn't bring myfaces
Javascript to Mojarra users. The Mojarra Javascript needs a lot of
improvement...
Best Regards,
Ganesh
> -1 b/c that adds an odd dependency to tomahawk...
> mfx:xyz does make sense to be the home for myfaces core "improvements".
>
> -M
>
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Apr 27, 2009 at 3:05 PM, Werner Punz <we...@gmail.com> wrote:
> I am somewhat against using hacks or spec weaknesses in this level
> because the next revision might close this loophole.
ok, I am fine to give up on that.
> My preferred option also would be mfx:ajax instead
Good.
> but tomahawk also is with me!
-1 b/c that adds an odd dependency to tomahawk...
mfx:xyz does make sense to be the home for myfaces core "improvements".
-M
>
> Werner
>
>
> Matthias Wessendorf schrieb:
>>
>> On Mon, Apr 27, 2009 at 2:46 PM, Werner Punz <we...@gmail.com>
>> wrote:
>>>
>>> I vetoed following options:
>>>
>>> 2.) optimization options as attributes of f:ajax
>>> 3.) optimization options within f:attributes nested in f:ajax
>>>
>>> The reason for this is, f: is a spec namespace which we cannot
>>> alter!
>>
>> we don't alter it. We just abuse a weakness in the spec (in facelets)
>>
>>> So f:ajax and options within f:ajax is out of the question!
>>> This simply would break spec behavior and probably would be
>>> prohibited by the TCK anyway!
>>
>> I doubt that the TCK is able to check that
>>
>>> In the past we relied on the t: namespace for such behavior
>>> and I personally thing we should follow the way for future extensions as
>>> well!
>>
>> my only problem is that everybody has to use tomahawk for that.
>> And I am totally -1 on that.
>>
>> Introducing some IMPL specific lib (-> mfx:ajax) does make much more
>> sense,
>> instead of putting things like that to tomahawk.
>>
>> If we can't agree on the f:ajax "hack", let's think about mfx:ajax...
>>
>> -M
>>
>>>
>>> Werner
>>> (
>>> No I am not from the United Nations (although I would not mind to have a
>>> UN
>>> salary ;-)
>>> )
>>>
>>>
>>>
>>> Ganesh schrieb:
>>>>
>>>> Hi,
>>>>
>>>> Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
>>>> [1] +3, 1 veto
>>>> [2] +1, 3 vetoes
>>>> [3] +0, 3 vetoes
>>>> [4] +1, 0 vetoes
>>>>
>>>> Thus, no consensus has been reached by this vote. This is, what the
>>>> decision making process on
>>>> http://apache.org/foundation/how-it-works.html#decision-making
>>>> prescribes:
>>>>
>>>> >>The rules require that a negative vote includes an alternative
>>>> proposal
>>>> or a detailed explanation of the reasons for the negative vote. The
>>>> community then tries to gather consensus on an alternative proposal that
>>>> resolves the issue. In the great majority of cases, the concerns leading
>>>> to
>>>> the negative vote can be addressed.
>>>> This process is called "consensus gathering" and we consider it a very
>>>> important indication of a healthy community.<<
>>>>
>>>> So, as everybody has given alternative proposals, all vetoers are asked
>>>> to
>>>> give detailed explanations for their negative votes to enable consensus
>>>> gathering. My personal observation is that everybody was pretty fast
>>>> with
>>>> emitting vetoes making me feel I'm at the UNO security council :-) Imho
>>>> and
>>>> though I can't emit a binding vote solutions [1] to [3] all aren't that
>>>> bad.
>>>> Maybe everybody who emitted a veto could consider weakening it to a +0
>>>> thus
>>>> opening the path for a majority decision?
>>>>
>>>> Best Regards,
>>>> Ganesh
>>>>
>>>> Ganesh schrieb:
>>>> > Hi,
>>>> >
>>>> > We are trying to agree on a way to include the optimization options
>>>> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
>>>> Javascript with the MyFaces JSF 2.0 implementation.
>>>> > We've got 4 different proposed solutions, each has been checked for
>>>> technical feasability:
>>>> >
>>>> > 1.) extra options packed in a new t:ajax tag 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
>>>> > Please consider the solutions and vote! See previous mails on this
>>>> list
>>>> with "f:ajax and MyFaces extensions" in the subject for further details.
>>>> >
>>>> > Please note:
>>>> > This vote is "majority approval" with a minimum of three +1 votes.
>>>> This
>>>> is a code modification vote [1], so you can veto a solution with a vote
>>>> of
>>>> -1. Please vote whole numbers. You can give a vote on each of the 4
>>>> solutions. E.g. you can vote:
>>>> >
>>>> > 1.) +1
>>>> > 2.) +1
>>>> > 3.) +0
>>>> > 4.) -1
>>>> >
>>>> > The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and
>>>> ends
>>>> on 2009-04-27 09:55 a.m.
>>>> >
>>>> > ------------------------------------------------
>>>> > [ ] +1 - you favourize this solution
>>>> > [ ] +0 - you don't like this solution
>>>> > [ ] -1 - you veto this solution
>>>> >
>>>> >
>>>> > Best Regards,
>>>> > Ganesh Jung
>>>> >
>>>> > [1] http://www.apache.org/foundation/voting.html
>>>>
>>>>
>>>
>>
>>
>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Apr 27, 2009 at 3:09 PM, Werner Punz <we...@gmail.com> wrote:
> Ok since Matthias
> gave me a clear ok that it is within the scope of the spec
>
> +0 for [2] and [3]
>
> from me, although I am not to happy with it.
> I know we do similar things within our code to use
> loopholes from the spec, but doing those things on codelevel
> is quite different than doing it on tag level where people often
> use the stuff who are not programmers but page designers.
so, why not +1 on [4] ? :) Oh, I see you did.
Great !
So, to make it a bit more fun. Here is my new vote:
1.) -1
2.) -0
3.) -0
4.) +1
READ => only mfx:ajax is preferable for me, now.
-M
>
> Anyway, I have recast my vote down to [0] for both issues
> because they do not break the spec even within the bounds
> of a TCK...
>
> Werner
>
>
> Werner Punz schrieb:
>>
>> I am somewhat against using hacks or spec weaknesses in this level
>> because the next revision might close this loophole.
>> My preferred option also would be mfx:ajax instead
>> but tomahawk also is with me!
>>
>> Werner
>>
>>
>> Matthias Wessendorf schrieb:
>>>
>>> On Mon, Apr 27, 2009 at 2:46 PM, Werner Punz <we...@gmail.com>
>>> wrote:
>>>>
>>>> I vetoed following options:
>>>>
>>>> 2.) optimization options as attributes of f:ajax
>>>> 3.) optimization options within f:attributes nested in f:ajax
>>>>
>>>> The reason for this is, f: is a spec namespace which we cannot
>>>> alter!
>>>
>>> we don't alter it. We just abuse a weakness in the spec (in facelets)
>>>
>>>> So f:ajax and options within f:ajax is out of the question!
>>>> This simply would break spec behavior and probably would be
>>>> prohibited by the TCK anyway!
>>>
>>> I doubt that the TCK is able to check that
>>>
>>>> In the past we relied on the t: namespace for such behavior
>>>> and I personally thing we should follow the way for future extensions as
>>>> well!
>>>
>>> my only problem is that everybody has to use tomahawk for that.
>>> And I am totally -1 on that.
>>>
>>> Introducing some IMPL specific lib (-> mfx:ajax) does make much more
>>> sense,
>>> instead of putting things like that to tomahawk.
>>>
>>> If we can't agree on the f:ajax "hack", let's think about mfx:ajax...
>>>
>>> -M
>>>
>>>>
>>>> Werner
>>>> (
>>>> No I am not from the United Nations (although I would not mind to have a
>>>> UN
>>>> salary ;-)
>>>> )
>>>>
>>>>
>>>>
>>>> Ganesh schrieb:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
>>>>> [1] +3, 1 veto
>>>>> [2] +1, 3 vetoes
>>>>> [3] +0, 3 vetoes
>>>>> [4] +1, 0 vetoes
>>>>>
>>>>> Thus, no consensus has been reached by this vote. This is, what the
>>>>> decision making process on
>>>>> http://apache.org/foundation/how-it-works.html#decision-making
>>>>> prescribes:
>>>>>
>>>>> >>The rules require that a negative vote includes an alternative
>>>>> proposal
>>>>> or a detailed explanation of the reasons for the negative vote. The
>>>>> community then tries to gather consensus on an alternative proposal
>>>>> that
>>>>> resolves the issue. In the great majority of cases, the concerns
>>>>> leading to
>>>>> the negative vote can be addressed.
>>>>> This process is called "consensus gathering" and we consider it a very
>>>>> important indication of a healthy community.<<
>>>>>
>>>>> So, as everybody has given alternative proposals, all vetoers are asked
>>>>> to
>>>>> give detailed explanations for their negative votes to enable consensus
>>>>> gathering. My personal observation is that everybody was pretty fast
>>>>> with
>>>>> emitting vetoes making me feel I'm at the UNO security council :-) Imho
>>>>> and
>>>>> though I can't emit a binding vote solutions [1] to [3] all aren't that
>>>>> bad.
>>>>> Maybe everybody who emitted a veto could consider weakening it to a +0
>>>>> thus
>>>>> opening the path for a majority decision?
>>>>>
>>>>> Best Regards,
>>>>> Ganesh
>>>>>
>>>>> Ganesh schrieb:
>>>>> > Hi,
>>>>> >
>>>>> > We are trying to agree on a way to include the optimization options
>>>>> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
>>>>> Javascript with the MyFaces JSF 2.0 implementation.
>>>>> > We've got 4 different proposed solutions, each has been checked for
>>>>> technical feasability:
>>>>> >
>>>>> > 1.) extra options packed in a new t:ajax tag 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
>>>>> > Please consider the solutions and vote! See previous mails on this
>>>>> list
>>>>> with "f:ajax and MyFaces extensions" in the subject for further
>>>>> details.
>>>>> >
>>>>> > Please note:
>>>>> > This vote is "majority approval" with a minimum of three +1 votes.
>>>>> This
>>>>> is a code modification vote [1], so you can veto a solution with a vote
>>>>> of
>>>>> -1. Please vote whole numbers. You can give a vote on each of the 4
>>>>> solutions. E.g. you can vote:
>>>>> >
>>>>> > 1.) +1
>>>>> > 2.) +1
>>>>> > 3.) +0
>>>>> > 4.) -1
>>>>> >
>>>>> > The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and
>>>>> ends
>>>>> on 2009-04-27 09:55 a.m.
>>>>> >
>>>>> > ------------------------------------------------
>>>>> > [ ] +1 - you favourize this solution
>>>>> > [ ] +0 - you don't like this solution
>>>>> > [ ] -1 - you veto this solution
>>>>> >
>>>>> >
>>>>> > Best Regards,
>>>>> > Ganesh Jung
>>>>> >
>>>>> > [1] http://www.apache.org/foundation/voting.html
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Werner Punz <we...@gmail.com>.
Ok since Matthias
gave me a clear ok that it is within the scope of the spec
+0 for [2] and [3]
from me, although I am not to happy with it.
I know we do similar things within our code to use
loopholes from the spec, but doing those things on codelevel
is quite different than doing it on tag level where people often
use the stuff who are not programmers but page designers.
Anyway, I have recast my vote down to [0] for both issues
because they do not break the spec even within the bounds
of a TCK...
Werner
Werner Punz schrieb:
> I am somewhat against using hacks or spec weaknesses in this level
> because the next revision might close this loophole.
> My preferred option also would be mfx:ajax instead
> but tomahawk also is with me!
>
> Werner
>
>
> Matthias Wessendorf schrieb:
>> On Mon, Apr 27, 2009 at 2:46 PM, Werner Punz <we...@gmail.com>
>> wrote:
>>> I vetoed following options:
>>>
>>> 2.) optimization options as attributes of f:ajax
>>> 3.) optimization options within f:attributes nested in f:ajax
>>>
>>> The reason for this is, f: is a spec namespace which we cannot
>>> alter!
>>
>> we don't alter it. We just abuse a weakness in the spec (in facelets)
>>
>>> So f:ajax and options within f:ajax is out of the question!
>>> This simply would break spec behavior and probably would be
>>> prohibited by the TCK anyway!
>>
>> I doubt that the TCK is able to check that
>>
>>> In the past we relied on the t: namespace for such behavior
>>> and I personally thing we should follow the way for future extensions as
>>> well!
>>
>> my only problem is that everybody has to use tomahawk for that.
>> And I am totally -1 on that.
>>
>> Introducing some IMPL specific lib (-> mfx:ajax) does make much more
>> sense,
>> instead of putting things like that to tomahawk.
>>
>> If we can't agree on the f:ajax "hack", let's think about mfx:ajax...
>>
>> -M
>>
>>>
>>> Werner
>>> (
>>> No I am not from the United Nations (although I would not mind to
>>> have a UN
>>> salary ;-)
>>> )
>>>
>>>
>>>
>>> Ganesh schrieb:
>>>> Hi,
>>>>
>>>> Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
>>>> [1] +3, 1 veto
>>>> [2] +1, 3 vetoes
>>>> [3] +0, 3 vetoes
>>>> [4] +1, 0 vetoes
>>>>
>>>> Thus, no consensus has been reached by this vote. This is, what the
>>>> decision making process on
>>>> http://apache.org/foundation/how-it-works.html#decision-making
>>>> prescribes:
>>>>
>>>> >>The rules require that a negative vote includes an alternative
>>>> proposal
>>>> or a detailed explanation of the reasons for the negative vote. The
>>>> community then tries to gather consensus on an alternative proposal
>>>> that
>>>> resolves the issue. In the great majority of cases, the concerns
>>>> leading to
>>>> the negative vote can be addressed.
>>>> This process is called "consensus gathering" and we consider it a very
>>>> important indication of a healthy community.<<
>>>>
>>>> So, as everybody has given alternative proposals, all vetoers are
>>>> asked to
>>>> give detailed explanations for their negative votes to enable consensus
>>>> gathering. My personal observation is that everybody was pretty fast
>>>> with
>>>> emitting vetoes making me feel I'm at the UNO security council :-)
>>>> Imho and
>>>> though I can't emit a binding vote solutions [1] to [3] all aren't
>>>> that bad.
>>>> Maybe everybody who emitted a veto could consider weakening it to a
>>>> +0 thus
>>>> opening the path for a majority decision?
>>>>
>>>> Best Regards,
>>>> Ganesh
>>>>
>>>> Ganesh schrieb:
>>>> > Hi,
>>>> >
>>>> > We are trying to agree on a way to include the optimization options
>>>> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
>>>> Javascript with the MyFaces JSF 2.0 implementation.
>>>> > We've got 4 different proposed solutions, each has been checked for
>>>> technical feasability:
>>>> >
>>>> > 1.) extra options packed in a new t:ajax tag 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
>>>> > Please consider the solutions and vote! See previous mails on
>>>> this list
>>>> with "f:ajax and MyFaces extensions" in the subject for further
>>>> details.
>>>> >
>>>> > Please note:
>>>> > This vote is "majority approval" with a minimum of three +1
>>>> votes. This
>>>> is a code modification vote [1], so you can veto a solution with a
>>>> vote of
>>>> -1. Please vote whole numbers. You can give a vote on each of the 4
>>>> solutions. E.g. you can vote:
>>>> >
>>>> > 1.) +1
>>>> > 2.) +1
>>>> > 3.) +0
>>>> > 4.) -1
>>>> >
>>>> > The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and
>>>> ends
>>>> on 2009-04-27 09:55 a.m.
>>>> >
>>>> > ------------------------------------------------
>>>> > [ ] +1 - you favourize this solution
>>>> > [ ] +0 - you don't like this solution
>>>> > [ ] -1 - you veto this solution
>>>> >
>>>> >
>>>> > Best Regards,
>>>> > Ganesh Jung
>>>> >
>>>> > [1] http://www.apache.org/foundation/voting.html
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Werner Punz <we...@gmail.com>.
I am somewhat against using hacks or spec weaknesses in this level
because the next revision might close this loophole.
My preferred option also would be mfx:ajax instead
but tomahawk also is with me!
Werner
Matthias Wessendorf schrieb:
> On Mon, Apr 27, 2009 at 2:46 PM, Werner Punz <we...@gmail.com> wrote:
>> I vetoed following options:
>>
>> 2.) optimization options as attributes of f:ajax
>> 3.) optimization options within f:attributes nested in f:ajax
>>
>> The reason for this is, f: is a spec namespace which we cannot
>> alter!
>
> we don't alter it. We just abuse a weakness in the spec (in facelets)
>
>> So f:ajax and options within f:ajax is out of the question!
>> This simply would break spec behavior and probably would be
>> prohibited by the TCK anyway!
>
> I doubt that the TCK is able to check that
>
>> In the past we relied on the t: namespace for such behavior
>> and I personally thing we should follow the way for future extensions as
>> well!
>
> my only problem is that everybody has to use tomahawk for that.
> And I am totally -1 on that.
>
> Introducing some IMPL specific lib (-> mfx:ajax) does make much more sense,
> instead of putting things like that to tomahawk.
>
> If we can't agree on the f:ajax "hack", let's think about mfx:ajax...
>
> -M
>
>>
>> Werner
>> (
>> No I am not from the United Nations (although I would not mind to have a UN
>> salary ;-)
>> )
>>
>>
>>
>> Ganesh schrieb:
>>> Hi,
>>>
>>> Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
>>> [1] +3, 1 veto
>>> [2] +1, 3 vetoes
>>> [3] +0, 3 vetoes
>>> [4] +1, 0 vetoes
>>>
>>> Thus, no consensus has been reached by this vote. This is, what the
>>> decision making process on
>>> http://apache.org/foundation/how-it-works.html#decision-making prescribes:
>>>
>>> >>The rules require that a negative vote includes an alternative proposal
>>> or a detailed explanation of the reasons for the negative vote. The
>>> community then tries to gather consensus on an alternative proposal that
>>> resolves the issue. In the great majority of cases, the concerns leading to
>>> the negative vote can be addressed.
>>> This process is called "consensus gathering" and we consider it a very
>>> important indication of a healthy community.<<
>>>
>>> So, as everybody has given alternative proposals, all vetoers are asked to
>>> give detailed explanations for their negative votes to enable consensus
>>> gathering. My personal observation is that everybody was pretty fast with
>>> emitting vetoes making me feel I'm at the UNO security council :-) Imho and
>>> though I can't emit a binding vote solutions [1] to [3] all aren't that bad.
>>> Maybe everybody who emitted a veto could consider weakening it to a +0 thus
>>> opening the path for a majority decision?
>>>
>>> Best Regards,
>>> Ganesh
>>>
>>> Ganesh schrieb:
>>> > Hi,
>>> >
>>> > We are trying to agree on a way to include the optimization options
>>> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
>>> Javascript with the MyFaces JSF 2.0 implementation.
>>> > We've got 4 different proposed solutions, each has been checked for
>>> technical feasability:
>>> >
>>> > 1.) extra options packed in a new t:ajax tag 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
>>> > Please consider the solutions and vote! See previous mails on this list
>>> with "f:ajax and MyFaces extensions" in the subject for further details.
>>> >
>>> > Please note:
>>> > This vote is "majority approval" with a minimum of three +1 votes. This
>>> is a code modification vote [1], so you can veto a solution with a vote of
>>> -1. Please vote whole numbers. You can give a vote on each of the 4
>>> solutions. E.g. you can vote:
>>> >
>>> > 1.) +1
>>> > 2.) +1
>>> > 3.) +0
>>> > 4.) -1
>>> >
>>> > The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and ends
>>> on 2009-04-27 09:55 a.m.
>>> >
>>> > ------------------------------------------------
>>> > [ ] +1 - you favourize this solution
>>> > [ ] +0 - you don't like this solution
>>> > [ ] -1 - you veto this solution
>>> >
>>> >
>>> > Best Regards,
>>> > Ganesh Jung
>>> >
>>> > [1] http://www.apache.org/foundation/voting.html
>>>
>>>
>>
>
>
>
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Apr 27, 2009 at 2:46 PM, Werner Punz <we...@gmail.com> wrote:
> I vetoed following options:
>
> 2.) optimization options as attributes of f:ajax
> 3.) optimization options within f:attributes nested in f:ajax
>
> The reason for this is, f: is a spec namespace which we cannot
> alter!
we don't alter it. We just abuse a weakness in the spec (in facelets)
>
> So f:ajax and options within f:ajax is out of the question!
> This simply would break spec behavior and probably would be
> prohibited by the TCK anyway!
I doubt that the TCK is able to check that
> In the past we relied on the t: namespace for such behavior
> and I personally thing we should follow the way for future extensions as
> well!
my only problem is that everybody has to use tomahawk for that.
And I am totally -1 on that.
Introducing some IMPL specific lib (-> mfx:ajax) does make much more sense,
instead of putting things like that to tomahawk.
If we can't agree on the f:ajax "hack", let's think about mfx:ajax...
-M
>
>
> Werner
> (
> No I am not from the United Nations (although I would not mind to have a UN
> salary ;-)
> )
>
>
>
> Ganesh schrieb:
>>
>> Hi,
>>
>> Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
>> [1] +3, 1 veto
>> [2] +1, 3 vetoes
>> [3] +0, 3 vetoes
>> [4] +1, 0 vetoes
>>
>> Thus, no consensus has been reached by this vote. This is, what the
>> decision making process on
>> http://apache.org/foundation/how-it-works.html#decision-making prescribes:
>>
>> >>The rules require that a negative vote includes an alternative proposal
>> or a detailed explanation of the reasons for the negative vote. The
>> community then tries to gather consensus on an alternative proposal that
>> resolves the issue. In the great majority of cases, the concerns leading to
>> the negative vote can be addressed.
>> This process is called "consensus gathering" and we consider it a very
>> important indication of a healthy community.<<
>>
>> So, as everybody has given alternative proposals, all vetoers are asked to
>> give detailed explanations for their negative votes to enable consensus
>> gathering. My personal observation is that everybody was pretty fast with
>> emitting vetoes making me feel I'm at the UNO security council :-) Imho and
>> though I can't emit a binding vote solutions [1] to [3] all aren't that bad.
>> Maybe everybody who emitted a veto could consider weakening it to a +0 thus
>> opening the path for a majority decision?
>>
>> Best Regards,
>> Ganesh
>>
>> Ganesh schrieb:
>> > Hi,
>> >
>> > We are trying to agree on a way to include the optimization options
>> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
>> Javascript with the MyFaces JSF 2.0 implementation.
>> > We've got 4 different proposed solutions, each has been checked for
>> technical feasability:
>> >
>> > 1.) extra options packed in a new t:ajax tag 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
>> > Please consider the solutions and vote! See previous mails on this list
>> with "f:ajax and MyFaces extensions" in the subject for further details.
>> >
>> > Please note:
>> > This vote is "majority approval" with a minimum of three +1 votes. This
>> is a code modification vote [1], so you can veto a solution with a vote of
>> -1. Please vote whole numbers. You can give a vote on each of the 4
>> solutions. E.g. you can vote:
>> >
>> > 1.) +1
>> > 2.) +1
>> > 3.) +0
>> > 4.) -1
>> >
>> > The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and ends
>> on 2009-04-27 09:55 a.m.
>> >
>> > ------------------------------------------------
>> > [ ] +1 - you favourize this solution
>> > [ ] +0 - you don't like this solution
>> > [ ] -1 - you veto this solution
>> >
>> >
>> > Best Regards,
>> > Ganesh Jung
>> >
>> > [1] http://www.apache.org/foundation/voting.html
>>
>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Matthias Wessendorf <ma...@apache.org>.
1.) -1
2.) +1
3.) +0
4.) +1
-Matthias
On Fri, Apr 24, 2009 at 1:45 PM, Ganesh <ga...@j4fry.org> wrote:
> Hi,
>
> We are trying to agree on a way to include the optimization options
> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
> Javascript with the MyFaces JSF 2.0 implementation.
>
> We've got 4 different proposed solutions, each has been checked for
> technical feasability:
>
> 1.) extra options packed in a new t:ajax tag 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
>
> Please consider the solutions and vote! See previous mails on this list with
> "f:ajax and MyFaces extensions" in the subject for further details.
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes. This is a
> code modification vote [1], so you can veto a solution with a vote of -1.
> Please vote whole numbers. You can give a vote on each of the 4 solutions.
> E.g. you can vote:
>
> 1.) +1
> 2.) +1
> 3.) +0
> 4.) -1
>
> The vote lasts for 72 hours. It start on 2009-04-24 11:45 a.m. and ends on
> 2009-04-27 11:45 a.m.
>
> ------------------------------------------------
> [ ] +1 - you favourize this solution
> [ ] +0 - you don't like this solution
> [ ] -1 - you veto this solution
>
>
> Best Regards,
> Ganesh Jung
>
> [1] http://www.apache.org/foundation/voting.html
> <http://www.apache.org/foundation/voting.html#ReleaseVotes>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Cagatay Civici <ca...@gmail.com>.
[1] +1
[2] -1
[3] -1
[4] +0
On Fri, Apr 24, 2009 at 2:32 PM, Werner Punz <we...@gmail.com> wrote:
>
> [1] +1
> [2] -1
> [3] -1
> [4] +1
>
> Werner
>
>
>
> Ganesh schrieb:
>
> Hi,
>>
>> We are trying to agree on a way to include the optimization options
>> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
>> Javascript with the MyFaces JSF 2.0 implementation.
>>
>> We've got 4 different proposed solutions, each has been checked for
>> technical feasability:
>>
>> 1.) extra options packed in a new t:ajax tag 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
>>
>> Please consider the solutions and vote! See previous mails on this list
>> with "f:ajax and MyFaces extensions" in the subject for further details.
>>
>> Please note:
>> This vote is "majority approval" with a minimum of three +1 votes. This is
>> a code modification vote [1], so you can veto a solution with a vote of -1.
>> Please vote whole numbers. You can give a vote on each of the 4 solutions.
>> E.g. you can vote:
>>
>> 1.) +1
>> 2.) +1
>> 3.) +0
>> 4.) -1
>>
>> The vote lasts for 72 hours. It start on 2009-04-24 11:45 a.m. and ends on
>> 2009-04-27 11:45 a.m.
>>
>> ------------------------------------------------
>> [ ] +1 - you favourize this solution
>> [ ] +0 - you don't like this solution
>> [ ] -1 - you veto this solution
>>
>>
>> Best Regards,
>> Ganesh Jung
>>
>> [1] http://www.apache.org/foundation/voting.html <
>> http://www.apache.org/foundation/voting.html#ReleaseVotes>
>>
>>
>
Re: setup tomahawk 2.0
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Apr 27, 2009 at 4:53 PM, Ganesh <ga...@j4fry.org> wrote:
> Hi,
>
>>>> Lets's go ... now, implementing t:ajax involves upgrading tomhawk to 2.0
>>>> ... I offer to go for it.
>>>>
>>>> 1. Has someone set up a tomahawk20 branch?
>>>>
>>>
>>> Not that I know of the consensous was that the work on tomahawk will
>>> start as soon as we have the core in place...
>>> But I think you can prepare everything within our impl
>>> and then move it over to Tomahawk as soon as it is ready...
>>>
>>
>> was there already a thread on this one (making tomahawk 2.0) ?
>> I don't think so.
>>
>> -M
>>
>
> What means "have the core in place"? It'll take quite a bit, before it
> passes the TCK ...
sure :-) That should not stop creating a tomahawk2 branch...
-M
>>
>>
>>>
>>>
>>>>
>>>> 2. I guess not, so is it ok if I do so?
>>>>
>
> What do you think on this one? I'd have Mojarra to test tomahawk20 against.
>
> Best Regards,
> Ganesh
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
setup tomahawk 2.0
Posted by Ganesh <ga...@j4fry.org>.
Hi,
>>> Lets's go ... now, implementing t:ajax involves upgrading tomhawk to 2.0
>>> ... I offer to go for it.
>>>
>>> 1. Has someone set up a tomahawk20 branch?
>>>
>> Not that I know of the consensous was that the work on tomahawk will
>> start as soon as we have the core in place...
>> But I think you can prepare everything within our impl
>> and then move it over to Tomahawk as soon as it is ready...
>>
>
> was there already a thread on this one (making tomahawk 2.0) ?
> I don't think so.
>
> -M
>
What means "have the core in place"? It'll take quite a bit, before it
passes the TCK ...
>
>>
>>> 2. I guess not, so is it ok if I do so?
>>>
What do you think on this one? I'd have Mojarra to test tomahawk20 against.
Best Regards,
Ganesh
Re: Revised result: [VOTE] MyFaces 2.0 optimization options
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Apr 27, 2009 at 3:48 PM, Werner Punz <we...@gmail.com> wrote:
> Ganesh schrieb:
>>
>> Hi,
>>
>> Two voters have changed their votes, so here is the revised result:
>>
>> [1] +4, 0 vetoes
>> [2] +1, 2 vetoes
>> [3] +0, 2 vetoes
>> [4] +1, 0 vetoes
>>
>> Matthias, you paved the way for t:ajax :-)
>>
>> Lets's go ... now, implementing t:ajax involves upgrading tomhawk to 2.0
>> ... I offer to go for it.
>>
>> 1. Has someone set up a tomahawk20 branch?
>
> Not that I know of the consensous was that the work on tomahawk will
> start as soon as we have the core in place...
> But I think you can prepare everything within our impl
> and then move it over to Tomahawk as soon as it is ready...
was there already a thread on this one (making tomahawk 2.0) ?
I don't think so.
-M
>
>
>> 2. I guess not, so is it ok if I do so?
>> 3. Who are the current maintainers of tomhawk 1.1 und tomahawk 1.2?
>>
> Leonardo Uribe...
>
> Werner
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Werner Punz <we...@gmail.com>.
[1] +1
[2] -1
[3] -1
[4] +1
Werner
Ganesh schrieb:
> Hi,
>
> We are trying to agree on a way to include the optimization options
> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
> Javascript with the MyFaces JSF 2.0 implementation.
>
> We've got 4 different proposed solutions, each has been checked for
> technical feasability:
>
> 1.) extra options packed in a new t:ajax tag 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
>
> Please consider the solutions and vote! See previous mails on this list
> with "f:ajax and MyFaces extensions" in the subject for further details.
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes. This
> is a code modification vote [1], so you can veto a solution with a vote
> of -1. Please vote whole numbers. You can give a vote on each of the 4
> solutions. E.g. you can vote:
>
> 1.) +1
> 2.) +1
> 3.) +0
> 4.) -1
>
> The vote lasts for 72 hours. It start on 2009-04-24 11:45 a.m. and ends
> on 2009-04-27 11:45 a.m.
>
> ------------------------------------------------
> [ ] +1 - you favourize this solution
> [ ] +0 - you don't like this solution
> [ ] -1 - you veto this solution
>
>
> Best Regards,
> Ganesh Jung
>
> [1] http://www.apache.org/foundation/voting.html
> <http://www.apache.org/foundation/voting.html#ReleaseVotes>
>
[VOTE] MyFaces 2.0 optimization options
Posted by Ganesh <ga...@j4fry.org>.
Hi,
We are trying to agree on a way to include the optimization options
pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
Javascript with the MyFaces JSF 2.0 implementation.
We've got 4 different proposed solutions, each has been checked for technical feasability:
1.) extra options packed in a new t:ajax tag 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
Please consider the solutions and vote! See previous mails on this list
with "f:ajax and MyFaces extensions" in the subject for further details.
Please note:
This vote is "majority approval" with a minimum of three +1 votes. This
is a code modification vote [1], so you can veto a solution with a vote
of -1. Please vote whole numbers. You can give a vote on each of the 4
solutions. E.g. you can vote:
1.) +1
2.) +1
3.) +0
4.) -1
The vote lasts for 72 hours. It start on 2009-04-24 11:45 a.m. and ends
on 2009-04-27 11:45 a.m.
------------------------------------------------
[ ] +1 - you favourize this solution
[ ] +0 - you don't like this solution
[ ] -1 - you veto this solution
Best Regards,
Ganesh Jung
[1] http://www.apache.org/foundation/voting.html
<http://www.apache.org/foundation/voting.html#ReleaseVotes>
Re: Revised result: [VOTE] MyFaces 2.0 optimization options
Posted by Werner Punz <we...@gmail.com>.
Ganesh schrieb:
> Hi,
>
> Two voters have changed their votes, so here is the revised result:
>
> [1] +4, 0 vetoes
> [2] +1, 2 vetoes
> [3] +0, 2 vetoes
> [4] +1, 0 vetoes
>
> Matthias, you paved the way for t:ajax :-)
>
> Lets's go ... now, implementing t:ajax involves upgrading tomhawk to 2.0
> ... I offer to go for it.
>
> 1. Has someone set up a tomahawk20 branch?
Not that I know of the consensous was that the work on tomahawk will
start as soon as we have the core in place...
But I think you can prepare everything within our impl
and then move it over to Tomahawk as soon as it is ready...
> 2. I guess not, so is it ok if I do so?
> 3. Who are the current maintainers of tomhawk 1.1 und tomahawk 1.2?
>
Leonardo Uribe...
Werner
Revised result: [VOTE] MyFaces 2.0 optimization options
Posted by Ganesh <ga...@j4fry.org>.
Hi,
Two voters have changed their votes, so here is the revised result:
[1] +4, 0 vetoes
[2] +1, 2 vetoes
[3] +0, 2 vetoes
[4] +1, 0 vetoes
Matthias, you paved the way for t:ajax :-)
Lets's go ... now, implementing t:ajax involves upgrading tomhawk to 2.0
... I offer to go for it.
1. Has someone set up a tomahawk20 branch?
2. I guess not, so is it ok if I do so?
3. Who are the current maintainers of tomhawk 1.1 und tomahawk 1.2?
Best Regards,
Ganesh
Ganesh schrieb:
> Hi,
>
> Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
> [1] +3, 1 veto
> [2] +1, 3 vetoes
> [3] +0, 3 vetoes
> [4] +1, 0 vetoes
>
> Thus, no consensus has been reached by this vote. This is, what the
decision making process on
http://apache.org/foundation/how-it-works.html#decision-making prescribes:
>
> >>The rules require that a negative vote includes an alternative
proposal or a detailed explanation of the reasons for the negative vote.
The community then tries to gather consensus on an alternative proposal
that resolves the issue. In the great majority of cases, the concerns
leading to the negative vote can be addressed.
> This process is called "consensus gathering" and we consider it a
very important indication of a healthy community.<<
>
> So, as everybody has given alternative proposals, all vetoers are
asked to give detailed explanations for their negative votes to enable
consensus gathering. My personal observation is that everybody was
pretty fast with emitting vetoes making me feel I'm at the UNO security
council :-) Imho and though I can't emit a binding vote solutions [1] to
[3] all aren't that bad. Maybe everybody who emitted a veto could
consider weakening it to a +0 thus opening the path for a majority decision?
>
> Best Regards,
> Ganesh
>
> Ganesh schrieb:
> > Hi,
> >
> > We are trying to agree on a way to include the optimization options
pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
Javascript with the MyFaces JSF 2.0 implementation.
> > We've got 4 different proposed solutions, each has been checked for
technical feasability:
> >
> > 1.) extra options packed in a new t:ajax tag 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
> > Please consider the solutions and vote! See previous mails on this
list with "f:ajax and MyFaces extensions" in the subject for further
details.
> >
> > Please note:
> > This vote is "majority approval" with a minimum of three +1 votes.
This is a code modification vote [1], so you can veto a solution with a
vote of -1. Please vote whole numbers. You can give a vote on each of
the 4 solutions. E.g. you can vote:
> >
> > 1.) +1
> > 2.) +1
> > 3.) +0
> > 4.) -1
> >
> > The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and
ends on 2009-04-27 09:55 a.m.
> >
> > ------------------------------------------------
> > [ ] +1 - you favourize this solution
> > [ ] +0 - you don't like this solution
> > [ ] -1 - you veto this solution
> >
> >
> > Best Regards,
> > Ganesh Jung
> >
> > [1] http://www.apache.org/foundation/voting.html
>
>
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Werner Punz <we...@gmail.com>.
I vetoed following options:
2.) optimization options as attributes of f:ajax
3.) optimization options within f:attributes nested in f:ajax
The reason for this is, f: is a spec namespace which we cannot
alter!
So f:ajax and options within f:ajax is out of the question!
This simply would break spec behavior and probably would be
prohibited by the TCK anyway!
In the past we relied on the t: namespace for such behavior
and I personally thing we should follow the way for future extensions as
well!
Werner
(
No I am not from the United Nations (although I would not mind to have a
UN salary ;-)
)
Ganesh schrieb:
> Hi,
>
> Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
> [1] +3, 1 veto
> [2] +1, 3 vetoes
> [3] +0, 3 vetoes
> [4] +1, 0 vetoes
>
> Thus, no consensus has been reached by this vote. This is, what the
> decision making process on
> http://apache.org/foundation/how-it-works.html#decision-making prescribes:
>
> >>The rules require that a negative vote includes an alternative
> proposal or a detailed explanation of the reasons for the negative vote.
> The community then tries to gather consensus on an alternative proposal
> that resolves the issue. In the great majority of cases, the concerns
> leading to the negative vote can be addressed.
> This process is called "consensus gathering" and we consider it a very
> important indication of a healthy community.<<
>
> So, as everybody has given alternative proposals, all vetoers are asked
> to give detailed explanations for their negative votes to enable
> consensus gathering. My personal observation is that everybody was
> pretty fast with emitting vetoes making me feel I'm at the UNO security
> council :-) Imho and though I can't emit a binding vote solutions [1] to
> [3] all aren't that bad. Maybe everybody who emitted a veto could
> consider weakening it to a +0 thus opening the path for a majority
> decision?
>
> Best Regards,
> Ganesh
>
> Ganesh schrieb:
> > Hi,
> >
> > We are trying to agree on a way to include the optimization options
> pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
> Javascript with the MyFaces JSF 2.0 implementation.
> > We've got 4 different proposed solutions, each has been checked for
> technical feasability:
> >
> > 1.) extra options packed in a new t:ajax tag 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
> > Please consider the solutions and vote! See previous mails on this
> list with "f:ajax and MyFaces extensions" in the subject for further
> details.
> >
> > Please note:
> > This vote is "majority approval" with a minimum of three +1 votes.
> This is a code modification vote [1], so you can veto a solution with a
> vote of -1. Please vote whole numbers. You can give a vote on each of
> the 4 solutions. E.g. you can vote:
> >
> > 1.) +1
> > 2.) +1
> > 3.) +0
> > 4.) -1
> >
> > The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and
> ends on 2009-04-27 09:55 a.m.
> >
> > ------------------------------------------------
> > [ ] +1 - you favourize this solution
> > [ ] +0 - you don't like this solution
> > [ ] -1 - you veto this solution
> >
> >
> > Best Regards,
> > Ganesh Jung
> >
> > [1] http://www.apache.org/foundation/voting.html
>
>
Re: [VOTE] MyFaces 2.0 optimization options
Posted by Ganesh <ga...@j4fry.org>.
Hi,
Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
[1] +3, 1 veto
[2] +1, 3 vetoes
[3] +0, 3 vetoes
[4] +1, 0 vetoes
Thus, no consensus has been reached by this vote. This is, what the
decision making process on
http://apache.org/foundation/how-it-works.html#decision-making prescribes:
>>The rules require that a negative vote includes an alternative
proposal or a detailed explanation of the reasons for the negative vote.
The community then tries to gather consensus on an alternative proposal
that resolves the issue. In the great majority of cases, the concerns
leading to the negative vote can be addressed.
This process is called "consensus gathering" and we consider it a very
important indication of a healthy community.<<
So, as everybody has given alternative proposals, all vetoers are asked
to give detailed explanations for their negative votes to enable
consensus gathering. My personal observation is that everybody was
pretty fast with emitting vetoes making me feel I'm at the UNO security
council :-) Imho and though I can't emit a binding vote solutions [1] to
[3] all aren't that bad. Maybe everybody who emitted a veto could
consider weakening it to a +0 thus opening the path for a majority decision?
Best Regards,
Ganesh
Ganesh schrieb:
> Hi,
>
> We are trying to agree on a way to include the optimization options
pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
Javascript with the MyFaces JSF 2.0 implementation.
> We've got 4 different proposed solutions, each has been checked for
technical feasability:
>
> 1.) extra options packed in a new t:ajax tag 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
> Please consider the solutions and vote! See previous mails on this
list with "f:ajax and MyFaces extensions" in the subject for further
details.
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes.
This is a code modification vote [1], so you can veto a solution with a
vote of -1. Please vote whole numbers. You can give a vote on each of
the 4 solutions. E.g. you can vote:
>
> 1.) +1
> 2.) +1
> 3.) +0
> 4.) -1
>
> The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and
ends on 2009-04-27 09:55 a.m.
>
> ------------------------------------------------
> [ ] +1 - you favourize this solution
> [ ] +0 - you don't like this solution
> [ ] -1 - you veto this solution
>
>
> Best Regards,
> Ganesh Jung
>
> [1] http://www.apache.org/foundation/voting.html
Re: f:ajax and MyFaces extensions
Posted by Matthias Wessendorf <ma...@apache.org>.
On Fri, Apr 24, 2009 at 9:17 AM, Ganesh <ga...@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 <ganesh@j4fry.org
>> <ma...@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 <ganesh@j4fry.org
>> <ma...@j4fry.org> <mailto:ganesh@j4fry.org
>> <ma...@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
Posted by Werner Punz <we...@gmail.com>.
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 <ganesh@j4fry.org
>> <ma...@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 <ganesh@j4fry.org
>> <ma...@j4fry.org> <mailto:ganesh@j4fry.org
>> <ma...@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: [VOTE] MyFaces 2.0 optimization options
Posted by Ganesh <ga...@j4fry.org>.
Hi,
Intermediate result of the vote:
[1] +3, 1 veto
[2] +1, 3 vetoes
[3] +0, 3 vetoes
[4] +1, 0 vetoes
Matthias, I've attached below the description of the tomahawk solution.
I've come to like it, it brings our solution to Mojarra users and allows
for a more appealing interface and sensible defaults. Can you eventually
be convinced to withdraw your veto on [1]?
Best Regards,
Ganesh
> 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
Re: f:ajax and MyFaces extensions
Posted by Ganesh <ga...@j4fry.org>.
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 <ganesh@j4fry.org
> <ma...@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 <ganesh@j4fry.org
> <ma...@j4fry.org> <mailto:ganesh@j4fry.org
> <ma...@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
Posted by Cagatay Civici <ca...@gmail.com>.
Then just document t:ajax is an extension that's not compatible with RI.
On Thu, Apr 23, 2009 at 5:39 PM, Ganesh <ga...@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 <ganesh@j4fry.org <mailto:
>> ganesh@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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Wed, Apr 22, 2009 at 8:19 AM, Werner Punz <we...@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 <we...@gmail.com>
>>> wrote:
>>>>
>>>> Matthias Wessendorf schrieb:
>>>>>
>>>>> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Thu, Apr 23, 2009 at 6:39 PM, Ganesh <ga...@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 <ganesh@j4fry.org
>> <ma...@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
Posted by Ganesh <ga...@j4fry.org>.
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 <ganesh@j4fry.org
> <ma...@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
Posted by Cagatay Civici <ca...@gmail.com>.
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 <ga...@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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Wed, Apr 22, 2009 at 9:16 AM, Ganesh <ga...@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
Posted by Ganesh <ga...@j4fry.org>.
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
Posted by Werner Punz <we...@gmail.com>.
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
Posted by Werner Punz <we...@gmail.com>.
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
Posted by Ganesh <ga...@j4fry.org>.
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
Posted by Werner Punz <we...@gmail.com>.
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
Posted by Simon Kitching <sk...@apache.org>.
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
Posted by Ganesh <ga...@j4fry.org>.
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
Posted by Werner Punz <we...@gmail.com>.
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 <we...@gmail.com>
>> wrote:
>>> Matthias Wessendorf schrieb:
>>>> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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
Posted by Werner Punz <we...@gmail.com>.
Matthias Wessendorf schrieb:
> On Wed, Apr 22, 2009 at 7:54 AM, Werner Punz <we...@gmail.com> wrote:
>> Matthias Wessendorf schrieb:
>>> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Wed, Apr 22, 2009 at 7:54 AM, Werner Punz <we...@gmail.com> wrote:
> Matthias Wessendorf schrieb:
>>
>> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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
Posted by Werner Punz <we...@gmail.com>.
Matthias Wessendorf schrieb:
> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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...
Seriously most projects use facelets nowadays but I would not call JSP
dead, besides that the new component api simplifies things anyway, so it
is not that hard to provide something on api level.
Re: f:ajax and MyFaces extensions
Posted by Matthias Wessendorf <ma...@apache.org>.
On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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 <ga...@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
Posted by Werner Punz <we...@gmail.com>.
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
Posted by Simon Kitching <sk...@apache.org>.
Werner Punz schrieb:
> Matthias Wessendorf schrieb:
>> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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
Posted by Werner Punz <we...@gmail.com>.
Matthias Wessendorf schrieb:
> On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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.
Btw. so far I have not seen to many applications of jsf
outside of the html realm, I have seen the oracle demo
with their vt220 based rendering, and there is some old
wap code lingering around in myfaces, but outside of that?
On the other hand the load of abstractions within JSF does not make
things easier has not made things easier on the web side, especially
when we had to deal with ajax, or just simply turning off validation on
a case by case base...
Werner
Re: f:ajax and MyFaces extensions
Posted by Matthias Wessendorf <ma...@apache.org>.
On Tue, Apr 21, 2009 at 8:13 PM, Werner Punz <we...@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 <ga...@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
Posted by Werner Punz <we...@gmail.com>.
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...
Werner
Matthias Wessendorf schrieb:
> On Tue, Apr 21, 2009 at 6:42 PM, Ganesh <ga...@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
>>
>
>
>
Re: f:ajax and MyFaces extensions
Posted by Matthias Wessendorf <ma...@apache.org>.
On Tue, Apr 21, 2009 at 6:42 PM, Ganesh <ga...@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
Posted by Ganesh <ga...@j4fry.org>.
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
Posted by Werner Punz <we...@gmail.com>.
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
Posted by Alexander Bell <Al...@j4fry.org>.
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 <sk...@apache.org>
> Matthias Wessendorf schrieb:
> > On Fri, Apr 17, 2009 at 2:24 PM, Ganesh <ga...@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.Bell@j4fry.org
Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: f:ajax and MyFaces extensions
Posted by Simon Kitching <sk...@apache.org>.
Matthias Wessendorf schrieb:
> On Fri, Apr 17, 2009 at 2:24 PM, Ganesh <ga...@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
Re: f:ajax and MyFaces extensions
Posted by Matthias Wessendorf <ma...@apache.org>.
On Fri, Apr 17, 2009 at 2:24 PM, Ganesh <ga...@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
Posted by Ganesh <ga...@j4fry.org>.
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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Fri, Apr 17, 2009 at 1:35 PM, Simon Kitching <sk...@apache.org> wrote:
> Matthias Wessendorf schrieb:
>> On Fri, Apr 17, 2009 at 1:12 PM, Simon Kitching <sk...@apache.org> wrote:
>>> Matthias Wessendorf schrieb:
>>>> On Fri, Apr 17, 2009 at 12:41 PM, Ganesh <ga...@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
Posted by Simon Kitching <sk...@apache.org>.
Matthias Wessendorf schrieb:
> On Fri, Apr 17, 2009 at 1:12 PM, Simon Kitching <sk...@apache.org> wrote:
>> Matthias Wessendorf schrieb:
>>> On Fri, Apr 17, 2009 at 12:41 PM, Ganesh <ga...@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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Fri, Apr 17, 2009 at 1:12 PM, Simon Kitching <sk...@apache.org> wrote:
> Matthias Wessendorf schrieb:
>> On Fri, Apr 17, 2009 at 12:41 PM, Ganesh <ga...@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
Posted by Simon Kitching <sk...@apache.org>.
Matthias Wessendorf schrieb:
> On Fri, Apr 17, 2009 at 12:41 PM, Ganesh <ga...@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
Posted by Matthias Wessendorf <ma...@apache.org>.
On Fri, Apr 17, 2009 at 12:41 PM, Ganesh <ga...@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