On Mon, Apr 27, 2009 at 3:09 PM, Werner Punz <werner.p...@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 <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 >>>>> >>>>> >>>> >>> >>> >>> >> >> > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
