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 <werner.p...@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
