Return-Path: X-Original-To: apmail-myfaces-dev-archive@www.apache.org Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D8A4A109CA for ; Wed, 28 May 2014 16:08:58 +0000 (UTC) Received: (qmail 74805 invoked by uid 500); 28 May 2014 16:08:58 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 74756 invoked by uid 500); 28 May 2014 16:08:58 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 74749 invoked by uid 99); 28 May 2014 16:08:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 May 2014 16:08:58 +0000 X-ASF-Spam-Status: No, hits=2.6 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_GREY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [74.125.82.178] (HELO mail-we0-f178.google.com) (74.125.82.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 May 2014 16:08:54 +0000 Received: by mail-we0-f178.google.com with SMTP id u56so11234652wes.23 for ; Wed, 28 May 2014 09:08:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7RgG2p7oklFqdVAgDVG8nSSsb5iWyNWEcu7db/hZFuQ=; b=HxnZfLYbtv+tfRR7Qt3ROQ6/1EQla7iW8dE0XUeTEzpO28Z+CrxDA54Y8mhLKNT+EO KoY0BRqeJ/kKU8nBLhG3Wb21/irqeKdgoLFwU/CIYoB/9k4DAqHDaKY8C/J2E3eXqsjU srwQ7jnOoMnQWQmAuW2jpELwmUi4XJkGZx0POXJgiyOANS8g9uFgTjfxNwjRYeIeY5DR goRrbBxViB6JIfTrCZOabIG4i4+PLb/tnMdW2rjl+Cbp+Xsk93sW3F+4JBWOszUEUoxx KxkAGnEx2S2JZkA11ttETVRvF7aMrhmgp0tsHV32SIcvdA8qymkGgu4uoAaiEbf+iO2D 0h9A== X-Gm-Message-State: ALoCoQnc1Tx9498/rextF3IDOIuEA1QhqCjKRP24kJJAEUyZJW4MUXrPQIs7QZnP1tVwaNzeFBgF MIME-Version: 1.0 X-Received: by 10.194.19.161 with SMTP id g1mr886983wje.20.1401293312391; Wed, 28 May 2014 09:08:32 -0700 (PDT) Received: by 10.216.88.202 with HTTP; Wed, 28 May 2014 09:08:32 -0700 (PDT) In-Reply-To: References: <1398789127.19145.YahooMailNeo@web164806.mail.gq1.yahoo.com> <1400005881.20289.YahooMailNeo@web164805.mail.gq1.yahoo.com> <1400157017.92319.YahooMailNeo@web164801.mail.gq1.yahoo.com> <1400690049.28679.YahooMailNeo@web164803.mail.gq1.yahoo.com> Date: Wed, 28 May 2014 12:08:32 -0400 Message-ID: Subject: Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project From: Kito Mann To: MyFaces Development Content-Type: multipart/alternative; boundary=047d7b5d28581c95ff04fa780652 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b5d28581c95ff04fa780652 Content-Type: text/plain; charset=ISO-8859-1 My initial response is that this looks pretty cool. Not sure how it'll fit in with the JCP plans for JAX-RS MVC, but I like it in the JSF world. ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://w ww.enterprisejavanews.com * * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Wed, May 28, 2014 at 10:49 AM, Leonardo Uribe wrote: > Hi > > I have finally had some time to get a functional prototype out. For > the people interested, take a look at: > > https://github.com/lu4242/test-draft-actions-for-jsf > > The example does what we have discussed in this thread. This > is only a draft, and the intention is give us a better idea about this. > I have only tried it with MyFaces 2.2.3, but it should work with > Mojarra too. > > I think for JSF 2.2 we cannot do anymore. It is possible to imagine > other good tricks like a front controller and so on , but we need > to change the spec for that. > > The prototype is far to be fully functional, but it is simple and > clear enough to give the people an idea about what can be done > and if it is worth to do it or not. > > To run the prototype, just download the code and type in the > command line: > > mvn install > cd examples > mvn clean jetty:run > > look in localhost:8080 > > The next step after take a look at the prototype is propose a > vote to include it as a module for myfaces commons, but it will take > some time before that. > > Please share your reactions about this. Your opinions are welcomed. > > regards, > > Leonardo Uribe > > 2014-05-23 14:49 GMT+02:00 Leonardo Uribe : > > Hi > > > > DR>> *Regarding #{ma:sourceActionURL('renderOptions') : render the URL > > of the action > > DR>> How is the URL rendered? Through the RequestMapping of the method > > as defined with the Bean? > > DR>> And the attribute, params of the action defined are appended to the > URL? > > > > Good question Dora. > > > > For #{ma:sourceActionURL(...)} the idea is call > > viewHandler.getActionURL(...), append a custom query parameter called > > 'oamva', and then call externalContext.encodeActionURL(...) , so the > > final link could look like this: > > > > /myfaces-mvc-examples/sayhello.jsf?jfwid=-5tba0312z&oamva=button > > > > In this case we are adding a query param to a url that will be used > > later in a POST, I think it is justified the use of a query param for > > the command activation. The only thing to take care here is be sure > > that the target component should fulfit some strict conditions, by > > security reasons. Anyway, without view state the POST will not work. > > > > Theoretically, only the client window and the action must be append in > > the URL, the other parameters like the view state, the input and so on > > must be provided by the user manually. After all, this is something of > > "low level", you want to have some flexibility at the time of define > > the parameters, for some users that could be important. > > > > For ma:getLink, it uses the same logic for h:link, which is in > > org.apache.myfaces.shared.renderkit.html.util.OutcomeTargetUtils > > method getOutcomeTargetHref(facesContext, target). > > > > DR>> For $.post with this URL, when its not appended with the > > attribute or params, execute="@form" attribute of ma:defineAction is > > not used. > > DR>> Purpose of this attribute out of scope of jQuery post? > > > > A declaration of ma:defineAction component is always, always required, > > without exceptions. This component will always decoded and its action > > processed. > > > > Most of the time > > $(document.getElementById("#{ma:parentFormId()}")).serialize() will do > > the job of add all input fields in the current form, so in that sense > > it works as an f:ajax request. In JSF no matter where the f:ajax > > request is, all the input fields of the parent form are sent, no > > matter what the "execute" parameter says. By 2.2 spec, you know you > > should always provide javax.faces.ViewState and > > javax.faces.ClientWindow, so I think that's clear enough. In that > > sense, it works just like f:ajax, but there is no render response > > phase, instead the action defines what to render. It is responsibility > > of the user to send the proper parameters, of the components that will > > be processed. > > > > DR>> *autocomplete is transient and hence its not required to update > viewstate > > > > I don't get what do you want to say. This is different from a form > > POST, this is a javascript POST, autocomplete doesn't have sense in > > this case. > > > > DR>> Script integration via jQuery with action is flowless and awesome! > > > > That's the idea. Something easy to use and flexible enough to cover > > those rare cases where you need to get your hands dirty with > > javascript, but without break the nice part of JSF abstraction, which > > is be independent of protocols. > > > > These days I haven't had enough time to get it done, but I hope in > > this weekend to get something out and publish a draft on my Github > > account, so the people interested can take a look and see if these > > ideas are good enough and later vote for create a new module, with > > something clear in mind. This is trial and error, and nothing is > > certain, so no matter if something looks fancy or cool, a community > > vote is required to move forward from that point. > > > > regards, > > > > Leonardo Uribe > > > > 2014-05-21 18:34 GMT+02:00 Dora Rajappan : > >> > >> *Regarding #{ma:sourceActionURL('renderOptions') : render the URL of the > >> action > >> How is the URL rendered? Through the RequestMapping of the method as > defined > >> with the Bean? > >> And the attribute, params of the action defined are appended to the URL? > >> > >> For $.post with this URL, when its not appended with the attribute or > >> params, execute="@form" attribute of ma:defineAction is not used. > >> Purpose of this attribute out of scope of jQuery post? > >> > >> *autocomplete is transient and hence its not required to update > viewstate > >> > >> Script integration via jQuery with action is flowless and awesome! > >> > >> Regards, > >> Dora Rajappa > >> > >> On Monday, May 19, 2014 9:13 PM, Leonardo Uribe > wrote: > >> > >> > >> Hi > >> > >> DR>> How about @ViewAction("/section1", action="exportExcel") > >> > >> It will not work because you can't change the annotation definition. > >> In other words, we should make "action" parameter a reserved one. > >> Also, the parameter by itself can have a converter or validator or a > >> EL binding, so you need to define that too. That's why @ViewParam or > >> something that define the parameter is required. > >> > >> regards, > >> > >> Leonardo > >> > >> 2014-05-15 14:30 GMT+02:00 Dora Rajappan : > >>> Export > >>> excel can work > >>> when the definition is > >>> @ViewAction("/section1/*", action="exportExcel") > >>> How about > >>> @ViewAction("/section1", action="exportExcel") > >>> On Wednesday, May 14, 2014 12:01 AM, Dora Rajappan > >>> > >>> wrote: > >>> How will Export > >>> excel > >>> work when ViewAction is not defined as > >>> > >>> @ViewAction(value="/sayhello.xhtml", > >>> params= { > >>> @ViewParam(name="action", > >>> expectedValue="exportExcel") > >>> }) > >>> public void method3(@ViewParam String param1, > >>> @ViewParam("someOther") Integer param2) > >>> { > >>> but as @ViewAction("/section1/*", action="exportExcel") > >>> Is the latter not supported now? > >>> > >>> facelet function getLink for action processing is not a bad idea. > >>> On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe > wrote: > >>> Hi > >>> > >>> Ok, I think the idea about @ViewAction and @ViewParam is clear, I have > >>> implemented a fast prototype and it works well, there is a lot of > things > >>> we > >>> can do for improvement, however we should focus the attention in other > >>> areas so we can give the module a better structure. > >>> > >>> The next thing we need is how to combine javascript with JSF, > specifically > >>> in cases like this: > >>> > >>> > >>> > >>> > >>> The idea is provide an input box and then write some javascript lines > to > >>> make the component an autocomplete box, but the problem is we need to > >>> provide > >>> a URL that can be used to retrieve the values to fill the box. In my > >>> opinion, > >>> mix EL and javascript is the best in these cases, but things get > complex > >>> quickly when you need to provide parameters and so on. So I would like > to > >>> propose these facelet functions (better with examples): > >>> > >>> Export > excel > >>> > >>> and > >>> > >>> > >>> > >>> > >>> > >>> Render url from EL > expression > >>> > >>> #{ma:getLink(...)} work just like h:link but receives the outcome as > >>> parameter. > >>> The function append the request path and the client window id, so the > >>> final > >>> generated link will be something like this: > >>> > >>> > >>> > http://localhost:8080/myfaces-mvc-examples/sayhello.jsf?id=5&jfwid=1di8uhetf9&action=exportExcel > >>> > >>> #{ma:getLinkFrom(...)} just inject the link from a component that works > >>> just > >>> like h:link but it is just a wrapper, so the user can customize the > >>> parameters, > >>> when the EL function is called, the link is rendered taking the > parameters > >>> in the definition. The outcome by default is the page itself. > >>> > >>> > >>> Please note this proposal is something different from the one that > suggest > >>> to > >>> create the link just pointing to the method in the bean like > >>> #{ma:getLink('mybean', 'mymethod', params)}. After thinking about it, > the > >>> problem with that approach is the difficulty to do the match between > the > >>> link > >>> to generate and the method. EL does not consider annotated methods, so > it > >>> is > >>> not possible to scan the annotations from the EL unless you do a bypass > >>> over > >>> CDI. > >>> > >>> I think the approach proposed is something simple to understand, and it > >>> has > >>> the advantage that you can isolate the declaration of the link from the > >>> rendering, so the final javascript code will be easier to read. > >>> > >>> Finally we need something for the POST case, so the idea is append > >>> something > >>> like this: > >>> > >>>
>>> method="post" > >>> enctype="application/x-www-form-urlencoded"> > >>> .... > >>>
> >>> > >>> #{ma:encodeActionURL()} do what h:form does for encode the action url. > >>> Then, > >>> it is responsibility of the user to provide the view state and client > >>> window > >>> token in the request as data, so the postback can be processed > properly. > >>> In this case, the idea is the view scope will be available, but the > >>> component > >>> tree state will not be updated when POST goes back to the client, so > any > >>> changes on the component tree in the action will be ignored. > >>> > >>> JSF does not make any difference between GET and POST, so viewParam > will > >>> work just the same. What defines a postback in JSF is if the view state > >>> field is in the request or not. Theoretically, use #{ma:getLink(...)} > >>> should > >>> work too, but I think there are different cases. > >>> > >>> There is a contradiction in this case. Send a POST, provide the view > state > >>> token, do not restore the view but restore the view scope bean. The > >>> problem > >>> is > >>> after you make changes on the view scope beans you need to save those > >>> changes, > >>> and that could mean update the view state token, even if the beans are > >>> stored > >>> in the server (remember the beans can be serialized, for example in a > >>> cluster). > >>> > >>> If we take a look at the proposed goals: > >>> > >>> 1) possibility to use a normal JSF lifecycle for the first GET request > >>> 2) allow action handling and custom response for POST actions > >>> 3) normal action handling like in asp.net MVC + a EL util function to > >>> generate the action URL > >>> > >>> we cannot really make number 2 exactly as POST actions. It doesn't fit > >>> because > >>> "... JSF's core architecture is designed to be independent of specific > >>> protocols and markup. ...". > >>> > >>> Really the problem proposed in number 2 is not simple and we should > >>> analyze > >>> it > >>> carefully. In which cases do we really need that kind of action > handling? > >>> If > >>> we are thinking for example in a JSF component that defines an endpoint > >>> with > >>> a > >>> custom response (for example a captcha component), we need a component > >>> oriented > >>> solution, something closer as what we have for ajax. What we have > proposed > >>> here with @ViewAction works in the case the user needs to define an > >>> endpoint > >>> at the "page" level. > >>> > >>> Really the big problem is how to hook the javascript code, so the > updates > >>> of > >>> the view state on the client side can be properly chained. For example > in > >>> MyFaces there is a queue for all ajax request, but we need that the > >>> actions > >>> sent that requires update the view state can be synchronized with that > >>> ajax queue too. > >>> > >>> I think what we have already is enough useful for a module. After all, > we > >>> don't need to solve all the problems at once. > >>> > >>> Suggestions are welcomed. > >>> > >>> regards, > >>> > >>> Leonardo Uribe > >>> > >>> 2014-05-05 0:05 GMT+02:00 Leonardo Uribe : > >>>> Hi Thomas > >>>> > >>>> TA>> AFAIR now, your solutions seems to be just a replacement for > >>>> f:viewAction > >>>> TA>> + allow different handlers via URL parameters. > >>>> TA>> Its sound really lightweight and easy actually :) > >>>> TA>> Does it cover all our requirements from the earlier mails? > >>>> TA>> > >>>> > >>>> I think so, but we need to write some examples to be sure that the > syntax > >>>> cover > >>>> all cases. > >>>> > >>>> Instead put a Front Controller on top of the lifecycle, we can go with > >>>> this approach > >>>> and provide some methods to call JSF algorithm inline. We already have > >>>> some > >>>> code in VDL.createComponent(...) that does inline compilation, so it > >>>> is not really > >>>> hard to write the necessary lines to do so (if the code is properly > >>>> implemented > >>>> of course). The idea could be provide something like: > >>>> > >>>> JSFUtils.generatePage("/mypage.xhtml", ....) > >>>> > >>>> and internally we call the algorithm, and deal with the potential > >>>> problems. > >>>> > >>>> So, if the user really wants to go with a MVC framework and use JSF as > >>>> template > >>>> engine, it will be as simple as write the adapter for the framework. > >>>> We should not > >>>> reinvent the wheel in this case. So, all other cases not supported by > >>>> f:viewAction/f:viewParam, which should be very, very few, should be > done > >>>> writing > >>>> a servlet or using an MVC framework like JAX-RS, and if necessary > calling > >>>> JSF at render time. > >>>> > >>>> The nice part about reuse f:viewAction logic is that is something > >>>> proved, everybody > >>>> knows how it works, we are just extending the syntax to define > >>>> f:viewAction in > >>>> a more familiar way. In practice we need to write a custom component > >>>> extending > >>>> UIViewAction, but that's something easy, I have already done it and it > >>>> works. > >>>> > >>>> That should cover most of the cases. There are other cases that are > >>>> indirectly > >>>> related to this one, but after some review, it doesn't seem to be so > >>>> interesting > >>>> or useful, or can be too complex to implement properly, so we need to > >>>> wait and push > >>>> it into the next spec. Sometimes less is more. Let's see what happen. > >>>> > >>>>>> Whats the syntax for multiple params? -> > >>>>>> params="action=exportExcel&someOther=string"? > >>>>>> Maybe we could think about a more typesafe and readable way. e.g. > >>>>>> > >>>>>> @ViewAction(value="my.xhtml", params = { > >>>>>> @ViewParam(name="action", value="exportExcel"), > >>>>>> @ViewParam(name="someOther", value="string") > >>>>>> }) > >>>> > >>>> I was thinking about this: > >>>> > >>>> @ViewAction(value="/sayhello.xhtml", params="action=exportExcel") > >>>> public void method3(@ViewParam String param1, > >>>> @ViewParam("someOther") Integer param2) > >>>> { > >>>> > >>>> The method has two parts: one define the parameters that should be > >>>> present > >>>> and the other define the activation conditions, in this case, when > >>>> action=exportExcel. Please note to make @ViewParam("someOther"), we > >>>> need to associate value to the key name. So we could do something > >>>> like this: > >>>> > >>>> @ViewAction(value="/sayhello.xhtml", > >>>> params= { > >>>> @ViewParam(name="action", > >>>> expectedValue="exportExcel") > >>>> }) > >>>> public void method3(@ViewParam String param1, > >>>> @ViewParam("someOther") Integer param2) > >>>> { > >>>> > >>>> I think in this way it looks better. Thanks for the suggestion. > >>>> > >>>> regards, > >>>> > >>>> Leonardo > >>> > >>> > >>> > >>> > >> > >> > --047d7b5d28581c95ff04fa780652 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My initial response is that this looks pretty cool. Not su= re how it'll fit in with the JCP plans for JAX-RS MVC, but I like it in= the JSF world.

___

Kito D. Mann | @kito99 | Author, JSF in Action
Virtua, I= nc. | http://www.virtua= .com | JSF/Java EE training and consulting
http://www.JSFCentral.com | @jsfcen= tral
+1 203-998-0403

* Listen to the Enterprise Java Newscast:= http://www.enterprisejavanews.com
* JSFCentral Interviews Podcast: http://www.jsfcentra= l.com/resources/jsfcentralpodcasts/
* Sign up for the JSFCentral New= sletter: http://oi.vresp.com/?fid=3Dac048d0e17


On Wed, May 28, 2014 at 10:49 AM, Leonar= do Uribe <lu4242@gmail.com> wrote:
Hi

I have finally had some time to get a functional prototype out. For
the people interested, take a look at:

https://github.com/lu4242/test-draft-actions-for-jsf

The example does what we have discussed in this thread. This
is only a draft, and the intention is give us a better idea about this.
I have only tried it with MyFaces 2.2.3, but it should work with
Mojarra too.

I think for JSF 2.2 we cannot do anymore. It is possible to imagine
other good tricks like a front controller and so on , but we need
to change the spec for that.

The prototype is far to be fully functional, but it is simple and
clear enough to give the people an idea about what can be done
and if it is worth to do it or not.

To run the prototype, just download the code and type in the
command line:

mvn install
cd examples
mvn clean jetty:run

look in localhost:8080

The next step after take a look at the prototype is propose a
vote to include it as a module for myfaces commons, but it will take
some time before that.

Please share your reactions about this. Your opinions are welcomed.

regards,

Leonardo Uribe

2014-05-23 14:49 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:
> Hi
>
> DR>> *Regarding #{ma:sourceActionURL('renderOptions') : = render the URL
> of the action
> DR>> How is the URL rendered? Through the RequestMapping of the = method
> as defined with the Bean?
> DR>> And the attribute, params of the action defined are appende= d to the URL?
>
> Good question Dora.
>
> For #{ma:sourceActionURL(...)} the idea is call
> viewHandler.getActionURL(...), append a custom query parameter called<= br> > 'oamva', and then call externalContext.encodeActionURL(...) , = so the
> final link could look like this:
>
> /myfaces-mvc-examples/sayhello.jsf?jfwid=3D-5tba0312z&amp;oamva=3D= button
>
> In this case we are adding a query param to a url that will be used > later in a POST, I think it is justified the use of a query param for<= br> > the command activation. The only thing to take care here is be sure > that the target component should fulfit some strict conditions, by
> security reasons. Anyway, without view state the POST will not work. >
> Theoretically, only the client window and the action must be append in=
> the URL, the other parameters like the view state, the input and so on=
> must be provided by the user manually. After all, this is something of=
> "low level", you want to have some flexibility at the time o= f define
> the parameters, for some users that could be important.
>
> For ma:getLink, it uses the same logic for h:link, which is in
> org.apache.myfaces.shared.renderkit.html.util.OutcomeTargetUtils
> method getOutcomeTargetHref(facesContext, target).
>
> DR>> For $.post with this URL, when its not appended with the > attribute or params, execute=3D"@form" attribute of ma:defin= eAction is
> not used.
> DR>> Purpose of this attribute out of scope of jQuery post?
>
> A declaration of ma:defineAction component is always, always required,=
> without exceptions. This component will always decoded and its action<= br> > processed.
>
> Most of the time
> $(document.getElementById("#{ma:parentFormId()}")).serialize= () will do
> the job of add all input fields in the current form, so in that sense<= br> > it works as an f:ajax request. In JSF no matter where the f:ajax
> request is, all the input fields of the parent form are sent, no
> matter what the "execute" parameter says. By 2.2 spec, you k= now you
> should always provide javax.faces.ViewState and
> javax.faces.ClientWindow, so I think that's clear enough. In that<= br> > sense, it works just like f:ajax, but there is no render response
> phase, instead the action defines what to render. It is responsibility=
> of the user to send the proper parameters, of the components that will=
> be processed.
>
> DR>> *autocomplete is transient and hence its not required to up= date viewstate
>
> I don't get what do you want to say. This is different from a form=
> POST, this is a javascript POST, autocomplete doesn't have sense i= n
> this case.
>
> DR>> Script integration via jQuery with action is flowless and a= wesome!
>
> That's the idea. Something easy to use and flexible enough to cove= r
> those rare cases where you need to get your hands dirty with
> javascript, but without break the nice part of JSF abstraction, which<= br> > is be independent of protocols.
>
> These days I haven't had enough time to get it done, but I hope in=
> this weekend to get something out and publish a draft on my Github
> account, so the people interested can take a look and see if these
> ideas are good enough and later vote for create a new module, with
> something clear in mind. This is trial and error, and nothing is
> certain, so no matter if something looks fancy or cool, a community > vote is required to move forward from that point.
>
> regards,
>
> Leonardo Uribe
>
> 2014-05-21 18:34 GMT+02:00 Dora Rajappan <dorarajappan@yahoo.com>:
>>
>> *Regarding #{ma:sourceActionURL('renderOptions') : render = the URL of the
>> action
>> How is the URL rendered? Through the RequestMapping of the method = as defined
>> with the Bean?
>> And the attribute, params of the action defined are appended to th= e URL?
>>
>> For $.post with this URL, when its not appended with the attribute= or
>> params, execute=3D"@form" attribute of ma:defineAction i= s not used.
>> Purpose of this attribute out of scope of jQuery post?
>>
>> *autocomplete is transient and hence its not required to update vi= ewstate
>>
>> Script integration via jQuery with action is flowless and awesome!=
>>
>> Regards,
>> Dora Rajappa
>>
>> On Monday, May 19, 2014 9:13 PM, Leonardo Uribe <lu4242@gmail.com> wrote:
>>
>>
>> Hi
>>
>> DR>> How about @ViewAction("/section1", action=3D&= quot;exportExcel")
>>
>> It will not work because you can't change the annotation defin= ition.
>> In other words, we should make "action" parameter a rese= rved one.
>> Also, the parameter by itself can have a converter or validator or= a
>> EL binding, so you need to define that too. That's why @ViewPa= ram or
>> something that define the parameter is required.
>>
>> regards,
>>
>> Leonardo
>>
>> 2014-05-15 14:30 GMT+02:00 Dora Rajappan <dorarajappan@yahoo.com>:
>>> <a href=3D"#{ma:getLink('/section1/mypage?action= =3DexportExcel')}">Export
>>> excel</a>  can work
>>> when the definition is
>>>  @ViewAction("/section1/*", action=3D"expo= rtExcel")
>>> How about
>>>  @ViewAction("/section1", action=3D"export= Excel")
>>> On Wednesday, May 14, 2014 12:01 AM, Dora Rajappan
>>> <dorarajappan@yah= oo.com>
>>> wrote:
>>> How will  <a href=3D"#{ma:getLink('mypage?act= ion=3DexportExcel')}">Export
>>> excel</a>
>>> work when ViewAction is not defined as
>>>
>>> @ViewAction(value=3D"/sayhello.xhtml",
>>>                  =        params=3D {
>>>                  =            @ViewParam(name=3D"action&qu= ot;,
>>> expectedValue=3D"exportExcel")
>>>                  =        })
>>>    public void method3(@ViewParam String param1,
>>> @ViewParam("someOther") Integer param2)
>>>    {
>>> but  as @ViewAction("/section1/*", action=3D&qu= ot;exportExcel")
>>> Is the latter not supported now?
>>>
>>> facelet function getLink for action processing is not a bad id= ea.
>>> On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe <lu4242@gmail.com> wrote:
>>> Hi
>>>
>>> Ok, I think the idea about @ViewAction and @ViewParam is clear= , I have
>>> implemented a fast prototype and it works well, there is a lot= of things
>>> we
>>> can do for improvement, however we should focus the attention = in other
>>> areas so we can give the module a better structure.
>>>
>>> The next thing we need is how to combine javascript with JSF, = specifically
>>> in cases like this:
>>>
>>> <input id=3D"search"/>
>>> <script type=3D"text/javascript">
>>>    $('#search').autocomplete({
>>>        source: "#{some EL that return= a link to an action goes here}"
>>>    });
>>> </script>
>>>
>>> The idea is provide an input box and then write some javascrip= t lines to
>>> make the component an autocomplete box, but the problem is we = need to
>>> provide
>>> a URL that can be used to retrieve the values to fill the box.= In my
>>> opinion,
>>> mix EL and javascript is the best in these cases, but things g= et complex
>>> quickly when you need to provide parameters and so on. So I wo= uld like to
>>> propose these facelet functions (better with examples):
>>>
>>>    <a href=3D"#{ma:getLink('mypage?actio= n=3DexportExcel')}">Export excel</a>
>>>
>>> and
>>>
>>>    <ma:defineLink id=3D"mylink">
>>>        <f:param name=3D"action&quo= t; value=3D"renderMessage"/>
>>>    </ma:defineLink>
>>>
>>>    <a href=3D"#{ma:getLinkFrom('mylink&#= 39;)}">Render url from EL expression</a>
>>>
>>> #{ma:getLink(...)} work just like h:link but receives the outc= ome as
>>> parameter.
>>> The function append the request path and the client window id,= so the
>>> final
>>> generated link will be something like this:
>>>
>>>
>>> http://localhost:8080/myfaces-mvc-examples/sayhello.jsf?id=3D5&jfwi= d=3D1di8uhetf9&action=3DexportExcel
>>>
>>> #{ma:getLinkFrom(...)} just inject the link from a component t= hat works
>>> just
>>> like h:link but it is just a wrapper, so the user can customiz= e the
>>> parameters,
>>> when the EL function is called, the link is rendered taking th= e parameters
>>> in the definition. The outcome by default is the page itself.<= br> >>>
>>>
>>> Please note this proposal is something different from the one = that suggest
>>> to
>>> create the link just pointing to the method in the bean like >>> #{ma:getLink('mybean', 'mymethod', params)}. A= fter thinking about it, the
>>> problem with that approach is the difficulty to do the match b= etween the
>>> link
>>> to generate and the method. EL does not consider annotated met= hods, so it
>>> is
>>> not possible to scan the annotations from the EL unless you do= a bypass
>>> over
>>> CDI.
>>>
>>> I think the approach proposed is something simple to understan= d, and it
>>> has
>>> the advantage that you can isolate the declaration of the link= from the
>>> rendering, so the final javascript code will be easier to read= .
>>>
>>> Finally we need something for the POST case, so the idea is ap= pend
>>> something
>>> like this:
>>>
>>>    <form action=3D"#{ma:encodeActionURL()}&q= uot;
>>>          method=3D"post" >>>          enctype=3D"application/= x-www-form-urlencoded">
>>>        ....
>>>    </form>
>>>
>>> #{ma:encodeActionURL()} do what h:form does for encode the act= ion url.
>>> Then,
>>> it is responsibility of the user to provide the view state and= client
>>> window
>>> token in the request as data, so the postback can be processed= properly.
>>> In this case, the idea is the view scope will be available, bu= t the
>>> component
>>> tree state will not be updated when POST goes back to the clie= nt, so any
>>> changes on the component tree in the action will be ignored. >>>
>>> JSF does not make any difference between GET and POST, so view= Param will
>>> work just the same. What defines a postback in JSF is if the v= iew state
>>> field is in the request or not. Theoretically, use #{ma:getLin= k(...)}
>>> should
>>> work too, but I think there are different cases.
>>>
>>> There is a contradiction in this case. Send a POST, provide th= e view state
>>> token, do not restore the view but restore the view scope bean= . The
>>> problem
>>> is
>>> after you make changes on the view scope beans you need to sav= e those
>>> changes,
>>> and that could mean update the view state token, even if the b= eans are
>>> stored
>>> in the server (remember the beans can be serialized, for examp= le in a
>>> cluster).
>>>
>>> If we take a look at the proposed goals:
>>>
>>> 1) possibility to use a normal JSF lifecycle for the first GET= request
>>> 2) allow action handling and custom response for POST actions<= br> >>> 3) normal action handling like in asp.net MVC + a EL util function to
>>> generate the action URL
>>>
>>> we cannot really make number 2 exactly as POST actions. It doe= sn't fit
>>> because
>>> "... JSF’s core architecture is designed to be inde= pendent of specific
>>> protocols and markup. ...".
>>>
>>> Really the problem proposed in number 2 is not simple and we s= hould
>>> analyze
>>> it
>>> carefully. In which cases do we really need that kind of actio= n handling?
>>> If
>>> we are thinking for example in a JSF component that defines an= endpoint
>>> with
>>> a
>>> custom response (for example a captcha component), we need a c= omponent
>>> oriented
>>> solution, something closer as what we have for ajax. What we h= ave proposed
>>> here with @ViewAction works in the case the user needs to defi= ne an
>>> endpoint
>>> at the "page" level.
>>>
>>> Really the big problem is how to hook the javascript code, so = the updates
>>> of
>>> the view state on the client side can be properly chained. For= example in
>>> MyFaces there is a queue for all ajax request, but we need tha= t the
>>> actions
>>> sent that requires update the view state can be synchronized w= ith that
>>> ajax queue too.
>>>
>>> I think what we have already is enough useful for a module. Af= ter all, we
>>> don't need to solve all the problems at once.
>>>
>>> Suggestions are welcomed.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2014-05-05 0:05 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:
>>>> Hi Thomas
>>>>
>>>> TA>> AFAIR now, your solutions seems to be just a re= placement for
>>>> f:viewAction
>>>> TA>> + allow different handlers via URL parameters.<= br> >>>> TA>> Its sound really lightweight and easy actually = :)
>>>> TA>> Does it cover all our requirements from the ear= lier mails?
>>>> TA>>
>>>>
>>>> I think so, but we need to write some examples to be sure = that the syntax
>>>> cover
>>>> all cases.
>>>>
>>>> Instead put a Front Controller on top of the lifecycle, we= can go with
>>>> this approach
>>>> and provide some methods to call JSF algorithm inline. We = already have
>>>> some
>>>> code in VDL.createComponent(...) that does inline compilat= ion, so it
>>>> is not really
>>>> hard to write the necessary lines to do so (if the code is= properly
>>>> implemented
>>>> of course). The idea could be provide something like:
>>>>
>>>> JSFUtils.generatePage("/mypage.xhtml", ....)
>>>>
>>>> and internally we call the algorithm, and deal with the po= tential
>>>> problems.
>>>>
>>>> So, if the user really wants to go with a MVC framework an= d use JSF as
>>>> template
>>>> engine, it will be as simple as write the adapter for the = framework.
>>>> We should not
>>>> reinvent the wheel in this case. So, all other cases not s= upported by
>>>> f:viewAction/f:viewParam, which should be very, very few, = should be done
>>>> writing
>>>> a servlet or using an MVC framework like JAX-RS, and if ne= cessary calling
>>>> JSF at render time.
>>>>
>>>> The nice part about reuse f:viewAction logic is that is so= mething
>>>> proved, everybody
>>>> knows how it works, we are just extending the syntax to de= fine
>>>> f:viewAction in
>>>> a more familiar way. In practice we need to write a custom= component
>>>> extending
>>>> UIViewAction, but that's something easy, I have alread= y done it and it
>>>> works.
>>>>
>>>> That should cover most of the cases. There are other cases= that are
>>>> indirectly
>>>> related to this one, but after some review, it doesn't= seem to be so
>>>> interesting
>>>> or useful, or can be too complex to implement properly, so= we need to
>>>> wait and push
>>>> it into the next spec. Sometimes less is more. Let's s= ee what happen.
>>>>
>>>>>> Whats the syntax for multiple params? ->
>>>>>> params=3D"action=3DexportExcel&someOther= =3Dstring"?
>>>>>> Maybe we could think about a more typesafe and rea= dable way. e.g.
>>>>>>
>>>>>> @ViewAction(value=3D"my.xhtml", params = =3D {
>>>>>>      @ViewParam(name=3D"action= ", value=3D"exportExcel"),
>>>>>>      @ViewParam(name=3D"someOt= her", value=3D"string")
>>>>>> })
>>>>
>>>> I was thinking about this:
>>>>
>>>>    @ViewAction(value=3D"/sayhello.xhtml&quo= t;, params=3D"action=3DexportExcel")
>>>>    public void method3(@ViewParam String param1,=
>>>> @ViewParam("someOther") Integer param2)
>>>>    {
>>>>
>>>> The method has two parts: one define the parameters that s= hould be
>>>> present
>>>> and the other define the activation conditions, in this ca= se, when
>>>> action=3DexportExcel. Please note to make @ViewParam("= ;someOther"), we
>>>> need to associate value to the key name. So we could do so= mething
>>>> like this:
>>>>
>>>>    @ViewAction(value=3D"/sayhello.xhtml&quo= t;,
>>>>                 &n= bsp;        params=3D {
>>>>                 &n= bsp;              @ViewParam(name=3D&quo= t;action",
>>>> expectedValue=3D"exportExcel")
>>>>                 &n= bsp;        })
>>>>    public void method3(@ViewParam String param1,=
>>>> @ViewParam("someOther") Integer param2)
>>>>    {
>>>>
>>>> I think in this way it looks better. Thanks for the sugges= tion.
>>>>
>>>> regards,
>>>>
>>>> Leonardo
>>>
>>>
>>>
>>>
>>
>>

--047d7b5d28581c95ff04fa780652--