You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Dora Rajappan <do...@yahoo.com> on 2014/05/02 18:47:26 UTC
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Hi,
According to Thomas mojarra has a prototype mapping FasesServlet as action servlet with lifecycle id as param .
So this implementation will be part spec and will go to myfaces project!
I think the f:viewParam and f:viewAction is not used very much. It gets executed when the page is loaded.
Regarding Bean having RequestMapping and returning a view is same with faces-config mapping. And if its partial its like ajax. Good thing is the flexibility is added to the Bean.
Its different when its executing a lifecycle phase which is good to support and new and may go to myfaces commons project.
Regards,
Dora Rajappan.
On Wednesday, April 30, 2014 8:58 PM, Leonardo Uribe <lu...@gmail.com> wrote:
Hi
After doing some attempts I found that a syntax like the one in
spring mvc @RequestMapping fits better:
@ViewAction(value="/sayhello.xhtml", params="action=exportExcel")
public void method3()
{
Then in the page you can write something like this:
<h:link outcome="sayhello" value="Export to excel" target="_blank">
<f:param name="action" value="exportExcel"/>
</h:link>
This is nice because the url includes the client window id
automatically in the action.
@RequestMapping propose these fields for matching:
String[] headers
RequestMethod[] method
String[] params
String[] consumes
String[] produces
But from JSF perspective, the only interesting to add is params. To restrict
the action in case of a POST, we could add a custom param like
boolean processOnPostback
or something like that.
Theoretically, f:viewAction has "rendered" property to restrict the case
when the action is executed or not, but it is easier to understand the
annotation syntax to restrict the cases where the action should be executed.
In this way, we are adding what is useful and discarding the remaining
stuff that is just noise for JSF. If anyone feels add something extra can
be useful, this is a good moment to say it.
regards,
Leonardo Uribe
2014-04-30 14:14 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
> Hi Thomas
>
> TA> cool!
> TA>
> TA> Your ViewAction currently returns a string. Is it just a "html" string?
> TA>
>
> Since @ViewAction resembles f:viewAction the string is the outcome that is used
> to navigate on invoke application phase. It triggers a navigation. But we can
> do something else, in the wrapper of the method.
>
> TA> What about rendering a view/rewrite url like ->
> TA> @ViewAction("/actions/registragion/start")
> TA> public void View myAction(
> TA>
> TA> return new View("/views/registration/startRegistration.xhtml");
> TA> }
> TA>
>
> I think it is another different case, that probably will require
> another annotation. It is something confusing at first view, but
> I'll try to clarify it here.
>
> In an action oriented framework, the path is used to indicate
> the specific action. For example, /actions/registragion/start is a
> defined point, so as soon as the user activates it, usually
> clicking on the related link, something happens in the action
> and then the control pass to the view.
>
> But in a framework like JSF, the control moves from page to
> page. In other words, it is page centric. So, instead to move
> into a some intermediate state, the control should go directly to
> the page and after that, all actions done by components will be
> handled by the page itself. For example, a form submit is always
> send as an "action" of the page with these parameters:
>
> javax.faces.ViewState
> [form_clientId]_SUBMIT
> ....
>
> Then, decode() method of the form check which form was
> submitted and process the necessary operations.
>
> Now, let's see what happen with an action oriented framework,
> for example Spring MVC in a login form (taken from the
> performance comparison, removing the unnecessary parts):
>
> @Controller
> @Scope("request")
> @RequestMapping(value = "/home")
> public class LoginController
> {
>
> @RequestMapping(method = RequestMethod.GET)
> public String home(Map model)
> {
> model.put("loginForm", new LoginForm());
> return "home";
> }
> /*.. more code goes here..*/
>
> This is what is on the jsp:
>
> <form:form method="post" action="home.do" commandName="loginForm">
>
> The model here is different. The control belongs to LoginController,
> the page has not an associated "implicit" controller, and in the page
> you must write some lines to give back the control to the controller.
>
>
> Do things like that is a complete nonsense for JSF, because that's
> the kind of code that cause maintenance problems.
>
> There are two options:
>
> 1. Put a front controller that sends the control to the bean and then
> in the bean you can decide which page takes the control. From that
> point the control does not get back to the bean, and the inner
> controller (jsf lifecycle) takes care of form submission and the
> remaining code. A new annotation is required.
>
> or
>
> 2. Define an special query parameter with the action, so the action is
> activated based on the value provided in that field.
>
> For example:
>
> @ViewAction("/section1/*", actionEvent="getList")
> public void method2()
> {
> FacesContext facesContext = FacesContext.getCurrentInstance();
> /* .... generate custom response ... */
> facesContext.responseComplete()
> }
>
> or something more simplified
>
> @ViewAction("/section1/*", actionEvent="getList")
> public Content method2()
> {
> return new Content("a, b, c");
> }
>
> and do the necessary stuff on the background.
>
> I feel inclined to use option 2, because the front controller approach
> clash with some basic concepts of JSF.
>
> TA> Will it also cover Excel/PDF... export?
>
> Yes, I think so, but we need to try. Really with the discussion we
> are trying to understand what's going on and how to adapt it into
> JSF.
>
> If you take a look, the discussion is leading us to something
> "in the middle". Does it work? does it solve the problem found in JSF?
> That's something we need to find out.
>
> regards,
>
> Leonardo Uribe
>
>>
>> Regards,
>> Thomas
>>
>>
>>
>> 2014-04-29 20:02 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>
>>> Hi
>>>
>>> I have done a fast prototype, just to check how things could work and how
>>> the
>>> pieces can be grouped together, and there are some interesting ideas that
>>> are
>>> worth to consider.
>>>
>>> In JSF 2, when f:viewParam was added, some logic was added to create the
>>> view
>>> in two steps: first you create the view metadata, where f:viewParam and
>>> now
>>> f:viewAction lives and then you "fill" the view, executing facelets
>>> algorithm
>>> again and in that way create the full component hierarchy.
>>>
>>> One idea it came to my mind is create a ViewDeclarationLanguage wrapper
>>> and
>>> override getViewMetadata(...) method to inject a f:viewAction component
>>> according to the definition in the CDI bean. For example:
>>>
>>> @Named("sayHelloBean")
>>> @ActionController
>>> @RequestScoped
>>> public class SayHelloBean
>>> {
>>>
>>> @ViewAction("/section1/*")
>>> public String method2()
>>> {
>>>
>>> That makes all views that match with the pattern provided to have an extra
>>> f:viewAction component, with the existing rules that apply for them. You
>>> can
>>> also imagine something like this:
>>>
>>> @ViewAction("/section1/*")
>>> public String method2(@ViewParam String param1)
>>>
>>> What we are saying with the syntax is: "... all views that are are part of
>>> section1 will have a ViewAction listener and will have a view param called
>>> param1. ...".
>>>
>>> This approach the following advantages:
>>>
>>> - Provide a way to define view actions without override the html markup in
>>> every top level template page.
>>> - It reuse the existing logic for JSF view action, so it is easy to
>>> understand
>>> for the users.
>>> - It can be included in JSF 2.2.
>>> - JSF is still in control of the navigation at all times, because there is
>>> no
>>> Front Controller.
>>> - The context will be automatically managed by JSF.
>>>
>>> but also has the following limitations:
>>>
>>> - With an action source framework it is possible to define a wide range of
>>> conditions to activate the action. For example if the request is a GET or
>>> a
>>> POST, of if it sends some specific header, even take parameters from the
>>> path.
>>> In this solution, the viewId is used for pattern maching and only
>>> considers
>>> query parameters.
>>> - It bounds the action to a view, so if there is no view, there is no
>>> action.
>>>
>>>
>>> And we finally get to the central point of discussion: How much
>>> flexibility we
>>> really need or the users want to define view actions?
>>>
>>> Remember the first lines in JSF spec:
>>>
>>> "... JSF’s core architecture is designed to be independent of specific
>>> protocols and markup. ..."
>>>
>>> Now take a look for example about what JAX-RS spec says about:
>>>
>>> "... The following are the goals of the API: POJO-based, HTTP-centric,
>>> Format independence, Container independence, Inclusion in Java EE ..."
>>>
>>> In that sense, all other features provided by action source frameworks are
>>> just useless for JSF, besides include a way to declare view actions into
>>> CDI beans.
>>>
>>> If we review the related requeriments Thomas Andraschko provided:
>>>
>>> 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
>>>
>>> I think with the approach proposed we can comply with the requirements.
>>>
>>> Maybe we should forget about the rest, and focus our efforts in explore
>>> this approach.
>>>
>>> DR>> +1 for the idea. Are you going to have two sets of release jars with
>>> DR>> and without extensions ? Is it going to be a different project?
>>>
>>> It is still a proposal (please read the subject of the message), so it
>>> is too early to say something about.
>>>
>>> DR>> Spring MVC beans can be configured to be accessed from the
>>> ManagedBeans.
>>> DR>> You are talking about the spring beans integration in the jsf
>>> elements?
>>>
>>> The mail is clear in this. The idea is explore how to do things like with
>>> an action source framework, but in JSF 2.2 / CDI, probably writing a CDI
>>> extension. There is no integration code with a third party framework, the
>>> idea is found new ways to solve existing problems.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2014-04-29 18:32 GMT+02:00 Dora Rajappan <do...@yahoo.com>:
>>> > +1 for the idea. Are you going to have two sets of release jars with
>>> > and
>>> > without extensions ? Is it going to be a different project?
>>> >
>>> > Spring MVC beans can be configured to be accessed from the ManagedBeans.
>>> > You
>>> > are talking about the spring beans integration in the jsf elements?
>>> >
>>> > Regards,
>>> > Dora Rajappan.
>>> > On Friday, April 25, 2014 7:03 PM, Thomas Andraschko
>>> > <an...@gmail.com> wrote:
>>> > Hi,
>>> >
>>> > sounds good enough for a first prototype -> +1
>>> >
>>> > Regards,
>>> > Thomas
>>> >
>>> >
>>> > 2014-04-25 15:23 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>> >
>>> > Hi
>>> >
>>> > There are different things we would like to include in this module. For
>>> > now, let's focus on rethink how "actions" should be processed in JSF.
>>> >
>>> > To make things easier, let's start with a comparison between
>>> > f:viewAction
>>> > and
>>> > a solution that involves a front controller and some actions defines
>>> > using
>>> > annotations in a CDI bean.
>>> >
>>> > In the first case, the developer defines the action in the page using a
>>> > tag:
>>> >
>>> > SOLUTION 1:
>>> >
>>> > <f:metadata>
>>> > <f:viewParam name="id" value="#{personPage.id}"/>
>>> > <f:viewAction action="#{personPage.loadPerson}"/>
>>> > </f:metadata>
>>> >
>>> > The alternative approach to discuss here is use a managed bean that
>>> > defines
>>> > a path that will work as an starting point:
>>> >
>>> > SOLUTION 2:
>>> >
>>> > @Named("myBean")
>>> > @ActionController
>>> > @RequestScoped
>>> > public class MyBean
>>> > {
>>> > @Action("/actions/do/something")
>>> > // userId param with automatic converter lookup
>>> > public View myAction()
>>> > {
>>> > return new View("/views/registration/startRegistration.xhtml");
>>> > }
>>> > }
>>> >
>>> > There are multiple differences between both solutions:
>>> >
>>> > * <f:viewAction> requires a view to be defined, so when the
>>> > f:viewAction is
>>> > processed, there is a FacesContext, a client window set (if any) and
>>> > there
>>> > is a view context too. With the annotations there is no associated
>>> > view,
>>> > so it can't be a valid UIViewRoot at that moment.
>>> >
>>> > * The annotation approach allows navigation without being in a view.
>>> > With
>>> > f:viewAction it is possible to cause a navigation like with a
>>> > h:commandButton.
>>> >
>>> > * f:viewAction still requires a managed bean to handle the action. The
>>> > syntax
>>> > using annotations is more compact, because requires only the managed
>>> > bean.
>>> >
>>> > * f:viewAction is activated every time the page is loaded by first time
>>> > (in practice, every time a GET is processed), but with the
>>> > annotations
>>> > it is necessay to define the conditions under the action is
>>> > activated.
>>> >
>>> > I think f:viewAction and the annotation approach are different things,
>>> > even
>>> > if they share some similarities.
>>> >
>>> > JSF has been always a "page centric" framework. The developer write some
>>> > pages, but to define the navigation, the developer has the option of
>>> > write
>>> > some navigation rules or he/she can also use an implicit navigation.
>>> >
>>> > f:viewAction design fits really well with JSF, as long as you are
>>> > dealing
>>> > with
>>> > "view actions". But in some cases, the action doesn't have any
>>> > relationship
>>> > with any view. That's the case where an action defined into a managed
>>> > bean
>>> > has
>>> > sense.
>>> >
>>> > For example, when the user want to verify a condition for all pages
>>> > inside
>>> > a folder. If the condition is not valid, an specified page should be
>>> > rendered.
>>> > Some solutions for that problem are:
>>> >
>>> > 1. Create a filter and handle the logic there
>>> > 2. Create a ViewHandler wrapper, override createView(...) and handle the
>>> > logic
>>> > there.
>>> >
>>> > But it would be nice to have something like this:
>>> >
>>> > @Named("myBean")
>>> > @ActionController
>>> > @RequestScoped
>>> > public class CheckUserBean
>>> > {
>>> > @Priority(Priorities.USER)
>>> > @Action("/registration/*")
>>> > // userId param with automatic converter lookup
>>> > public View myAction()
>>> > {
>>> > if (the current flow is not active)
>>> > {
>>> > return new Navigation("registration");
>>> > }
>>> > // Otherwise continue to the expected page
>>> > return null;
>>> > }
>>> > }
>>> >
>>> > In this case we have an action that is executed based on a pattern, in a
>>> > specified moment, for a set of pages, and that could cause a navigation
>>> > to another page or could not affect the navigation and JSF lifecycle
>>> > takes
>>> > place as usual.
>>> >
>>> > The other kind of action proposed:
>>> >
>>> > @Action("/actions/do/something")
>>> > // userId param with automatic converter lookup
>>> > public View myAction()
>>> > {
>>> > return new View("/views/registration/startRegistration.xhtml");
>>> > }
>>> >
>>> > It can be something like this too:
>>> >
>>> > @Action("/actions/do/something")
>>> > // userId param with automatic converter lookup
>>> > public void myAction()
>>> > {
>>> > FacesContext facesContext = FacesContext.getCurrentInstance();
>>> >
>>> > /* ... generate text, pdf, xml or whatever ...*/
>>> >
>>> > facesContext.responseComplete();
>>> > }
>>> >
>>> > the responseComplete() cause the lifecycle to be skipped.
>>> >
>>> > I think these ideas does not overlap or replace the utility of
>>> > f:viewAction,
>>> > and instead the aim is solve a different problem. I'll try to make a
>>> > prototype with the ideas exposed here. I have some more ideas for the
>>> > other
>>> > requeriments we have, but for now the idea is focus on what looks more
>>> > important or useful.
>>> >
>>> > Suggestions are welcome.
>>> >
>>> > regards,
>>> >
>>> > Leonardo
>>> >
>>> > 2014-04-23 15:45 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>> >> Hi
>>> >>
>>> >> 2014-04-23 14:16 GMT+02:00 Thomas Andraschko
>>> >> <an...@gmail.com>:
>>> >>> LU>> 4) Allow action rendering in in a normal lifecycle:
>>> >>> LU>>
>>> >>> LU>> <ui:renderAction action="#{myBrean.myAction(
>>> >>> LU>bean.value, 1)}" />
>>> >>> LU>>
>>> >>> LU>
>>> >>> LU>Could you please describe better this case? So you execute the
>>> >>> action,
>>> >>> LU> but the lifecycle goes on as usual?
>>> >>
>>> >>
>>> >> TA> It's just a component, which renders the returned html string from
>>> >> the
>>> >> TA> action into the ResponseWriter.
>>> >> TA> Something like a include for the action return value.
>>> >> TA>
>>> >> TA>
>>> >> TA> This would be also helpful if we combine facelet rendering +
>>> >> actions.
>>> >> TA> In ASP.NET MVC, the action could also return a View/PartialView:
>>> >> TA>
>>> >> TA>
>>> >> TA>> @Named("myBean")
>>> >> TA>> @RequestScoped
>>> >> TA>> public class MyBean {
>>> >> TA>> @Action
>>> >> TA>> // userId param with automatic converter lookup
>>> >> TA>> public PartialView myAction(String myUrlParam, User
>>> >> userId)
>>> >> {
>>> >> TA>> return new
>>> >> TA>> PartialView("/META-INF/mylib/myincludes/myfile.xhtml");
>>> >> TA>> }
>>> >> TA>> }
>>> >> TA>
>>> >> TA> It would load the xhtml, renders the xhtml and return the rendered
>>> >> html
>>> >> TA> string - called via ui:renderAction or via URL.
>>> >> TA>
>>> >>
>>> >> So you mean use JSF as a template engine to render some html fragments.
>>> >> I think it can be done.
>>> >>
>>> >> This feature is something controversial, because it could be used
>>> >> wrongly.
>>> >> For example, you have a page fragment and you want to update it using
>>> >> this stuff and some javascript. Since you are bypassing JSF, the
>>> >> results
>>> >> can be unexpected, because JSF is no longer in control of the view
>>> >> state
>>> >> anymore. The right way is affect the component state (or the model
>>> >> state),
>>> >> so when it is rendered it gets updated. The best way to do it, is with
>>> >> ajax,
>>> >> because ajax knows about the relationship between different components.
>>> >>
>>> >> Also, you could have situations when the ids are not correctly
>>> >> generated,
>>> >> and at the end have duplicate ids. Again, the solution is add or remove
>>> >> the
>>> >> component from the component tree programmatically, so JSF can have
>>> >> the change to deal with this problem properly.
>>> >>
>>> >> More than a PartialView, I think in this case JSF is used as a raw html
>>> >> or
>>> >> xml generator. For example, the html in this case could be a formatted
>>> >> message and so on.
>>> >>
>>> >> I think it is better if we avoid the term "PartialView" and instead we
>>> >> provide
>>> >> something more abstract like "Response" or "MarkupFragment" or
>>> >> something like that. Something that indicates that this is not part of
>>> >> the
>>> >> view itself, and instead is part of the "client state".
>>> >>
>>> >>>
>>> >>>
>>> >>> I think we could also completely rebuild the GET functionality for
>>> >>> actions.
>>> >>> Maybe could just render the startRegistration.xhtml via a normal JSF
>>> >>> lifecycle after the action call.
>>> >>>
>>> >>>> @Named("myBean")
>>> >>>> @RequestScoped
>>> >>>> public class MyBean {
>>> >>>> @Action(mapping = "/actions/do/something")
>>> >>>
>>> >>>> // userId param with automatic converter lookup
>>> >>>> public View myAction() {
>>> >>>> return new
>>> >>>> View("/views/registration/startRegistration.xhtml");
>>> >>>> }
>>> >>>> }
>>> >>>
>>> >>
>>> >> It can be done. In fact, it works like a url rewriting. Maybe it is
>>> >> more
>>> >> straighforward for users after all, because with f:viewAction, you
>>> >> can't
>>> >> control the page, but with this, you can add some logic before the
>>> >> final page is processed, like for example a conditional and so on.
>>> >>
>>> >>> Just some ideas for a more complete add-on.
>>> >>> That would cover the "view" and "controller". The "model" are actually
>>> >>> the
>>> >>> beans via EL.
>>> >>>
>>> >>> Don't know if it really fits JSF or if there are better concepts - but
>>> >>> that
>>> >>> are almost all core features of ASP.NET MVC.
>>> >>>
>>> >>>
>>> >>
>>> >> I think what we are doing here instead is take the best we found from
>>> >> the
>>> >> things we know that works. The challenge is integrate in a coherent
>>> >> way.
>>> >>
>>> >> For example, JSF as a component oriented framework has the concept
>>> >> of clientIds associated with components. This is very helpful when you
>>> >> move code from one place to another, because the generated ids on
>>> >> the client side are updated properly. In an action oriented framework,
>>> >> that's
>>> >> a complete mess. The idea is preserve the JSF abstraction, that means
>>> >> components that can be assembled in a hierarchical way, and that also
>>> >> means this tree has a similar structure on the client.
>>> >>
>>> >> We can find workarounds. For example, bind the html generation to
>>> >> a component, so we say "... generate an html fragment, but keep in mind
>>> >> that chunk will be used in this component or a component with this
>>> >> client id ..." So, the fragment is encapsulated in a jsf component that
>>> >> implements NamingContainer and generates the specified clientId.
>>> >> That could work. But I suppose it should be MyFaces Core implementation
>>> >> specific, because we need to indicate to facelets the way how the ids
>>> >> should be generated.
>>> >>
>>> >> regards,
>>> >>
>>> >> Leonardo Uribe
>>> >>
>>> >>>
>>> >>> 2014-04-23 13:40 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>> >>>
>>> >>>> Hi
>>> >>>>
>>> >>>> 2014-04-23 11:54 GMT+02:00 Thomas Andraschko
>>> >>>> <an...@gmail.com>:
>>> >>>> TA> Hi,
>>> >>>> TA>
>>> >>>> TA> the most important question for me is actually:
>>> >>>> TA>
>>> >>>> TA> 1) How much should we really mix actions with facelets rendering?
>>> >>>> TA>
>>> >>>> TA> There are soooo many things to consider. As you already said in
>>> >>>> your
>>> >>>> specs
>>> >>>> TA> post: viewstate, windowid, viewscoped, ....
>>> >>>> TA>
>>> >>>>
>>> >>>> I think the best way to deal with facelets rendering is use the
>>> >>>> standard
>>> >>>> ajax.
>>> >>>> I know in an action source framework people have to do the ajax stuff
>>> >>>> "by hand", which means use the template framework to calculate a
>>> >>>> fragment
>>> >>>> of the response. That's a step back.
>>> >>>>
>>> >>>> Instead, this is for the case when you have a page in the client and
>>> >>>> you
>>> >>>> need
>>> >>>> to communicate with the server to get some information, but the page
>>> >>>> structure
>>> >>>> does not change. For example, an autocomplete component or a
>>> >>>> datatable
>>> >>>> component. In that case, you only need the data usually in json
>>> >>>> format,
>>> >>>> and
>>> >>>> there is a javascript already in place to deal with that data and
>>> >>>> change
>>> >>>> the
>>> >>>> state of the client.
>>> >>>>
>>> >>>> The point is deal with the context in general. So if you send a POST
>>> >>>> from
>>> >>>> the
>>> >>>> client, and you provide the windowid and the viewstate token, it
>>> >>>> should
>>> >>>> be
>>> >>>> processed, and the response should update the viewstate if necessary.
>>> >>>> That's why we need some javascript on the client to wire things up.
>>> >>>>
>>> >>>> It could be possible a complex case, where we need a json response
>>> >>>> but
>>> >>>> the response triggers an ajax update from the server. It can be done,
>>> >>>> with
>>> >>>> some javascript code.
>>> >>>>
>>> >>>> >
>>> >>>> > For me the most important things are actually:
>>> >>>> >
>>> >>>> > 1) possibility to use a normal JSF lifecycle for the first GET
>>> >>>> > request
>>> >>>>
>>> >>>> I agree with you, because in the first request you are just building
>>> >>>> the
>>> >>>> view,
>>> >>>> no special things there.
>>> >>>>
>>> >>>> > 2) allow action handling and custom response for POST actions
>>> >>>>
>>> >>>> Yes.
>>> >>>>
>>> >>>> > 3) normal action handling like in asp.net MVC + a EL util function
>>> >>>> > to
>>> >>>> > generate the action URL
>>> >>>> >
>>> >>>> > $('#input').autocomplete({
>>> >>>> > source: "#{action('myBean', 'myAction', params...)}"
>>> >>>> > });
>>> >>>> >
>>> >>>> > @Named("myBean")
>>> >>>> > @RequestScoped
>>> >>>> > public class MyBean {
>>> >>>> > @Action
>>> >>>> > // userId param with automatic converter lookup
>>> >>>> > public String myAction(String myUrlParam, User userId) {
>>> >>>> > return response;
>>> >>>> > }
>>> >>>> > }
>>> >>>> >
>>> >>>>
>>> >>>>
>>> >>>> Yes, that's one good point. I have seen too. It could be good to have
>>> >>>> an EL function that renders the endpoint url automatically. In this
>>> >>>> case,
>>> >>>> you don't really care how the endpoind url is generated, as long as
>>> >>>> when the javascript on the client side invokes the url you get the
>>> >>>> pointed method executed.
>>> >>>>
>>> >>>> You could also want to bind the url to the component itself. The case
>>> >>>> is
>>> >>>> you are writing a composite component and the component requires
>>> >>>> the url, so you annotate a method in the base component class to
>>> >>>> deal with this. In the GET case you don't have the view state, so the
>>> >>>> component state is not restored, but in the POST case you can
>>> >>>> submit the view state (for example calling a defined javascript
>>> >>>> function)
>>> >>>> and the code will execute an invokeOnComponent call on the server.
>>> >>>>
>>> >>>> > 4) Allow action rendering in in a normal lifecycle:
>>> >>>> >
>>> >>>> > <ui:renderAction action="#{myBrean.myAction(bean.value, 1)}" />
>>> >>>> >
>>> >>>>
>>> >>>> Could you please describe better this case? So you execute the
>>> >>>> action,
>>> >>>> but the lifecycle goes on as usual?
>>> >>>>
>>> >>>> > 5) Action + facelets rendering -> question 1
>>> >>>> > Currently no idea how a integration should look like.
>>> >>>> >
>>> >>>> >
>>> >>>>
>>> >>>> I still don't have clear this point, but I can imagine you can return
>>> >>>> XML from the server and parse it on the client somehow. Obviously
>>> >>>> we need to find out how to do it.
>>> >>>>
>>> >>>> regards,
>>> >>>>
>>> >>>> Leonardo Uribe
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> >
>>> >>>> >
>>> >>>> > 2014-04-22 18:24 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>> >>>> >
>>> >>>> >> Hi
>>> >>>> >>
>>> >>>> >> In few word, the difficulty in this stuff is the context. If you
>>> >>>> >> take
>>> >>>> >> a
>>> >>>> >> look
>>> >>>> >> at the example proposed:
>>> >>>> >>
>>> >>>> >> @Named("myBean")
>>> >>>> >> @RequestScoped
>>> >>>> >> public class MyBean implements Serializable {
>>> >>>> >>
>>> >>>> >> @RequestMapping(value = "/form1b.xhtml")
>>> >>>> >> public String form1() {
>>> >>>> >> String inputText1 = (String)
>>> >>>> >> FacesContext.getCurrentInstance().
>>> >>>> >>
>>> >>>> >> getExternalContext().getRequestParameterMap().get("inputText1");
>>> >>>> >> setValue("We set inputText1 manually to - " + inputText1);
>>> >>>> >> return "/form1b.xhtml";
>>> >>>> >> }
>>> >>>> >>
>>> >>>> >> }
>>> >>>> >>
>>> >>>> >> To call the method you need to restore the context first of the
>>> >>>> >> parent
>>> >>>> >> bean and also there is a call to
>>> >>>> >> FacesContext.getCurrentInstance(),
>>> >>>> >> so at that point it should be a valid FacesContext instance.
>>> >>>> >>
>>> >>>> >> In JSF 2.2 the lifecycle has 3 methods:
>>> >>>> >>
>>> >>>> >> //JSF 2.2: attach window
>>> >>>> >> _lifecycle.attachWindow(facesContext);
>>> >>>> >> // If this returns false, handle as follows:
>>> >>>> >> // call
>>> >>>> >> Lifecycle.execute(javax.faces.context.FacesContext)
>>> >>>> >> _lifecycle.execute(facesContext);
>>> >>>> >> // followed by
>>> >>>> >> Lifecycle.render(javax.faces.context.FacesContext).
>>> >>>> >> _lifecycle.render(facesContext);
>>> >>>> >>
>>> >>>> >> The idea is create a LifecycleWrapper that on lifecycle.execute()
>>> >>>> >> implements a front controller pattern, doing the necessary steps
>>> >>>> >> to
>>> >>>> >> get the bean from the underlying CDI container and call the
>>> >>>> >> method.
>>> >>>> >> If no method is called, continue as usual.
>>> >>>> >>
>>> >>>> >> The idea is not replicate all the features that an action source
>>> >>>> >> framework
>>> >>>> >> provides, just the important ones to deal with the cases we have
>>> >>>> >> found
>>> >>>> >> where this can be useful for JSF, or try to reutilize what's
>>> >>>> >> already
>>> >>>> >> available in JSF. It will take some time to get it out, but I
>>> >>>> >> think
>>> >>>> >> if
>>> >>>> >> we can solve the use cases proposed, the final result will be
>>> >>>> >> something
>>> >>>> >> valuable.
>>> >>>> >>
>>> >>>> >> regards,
>>> >>>> >>
>>> >>>> >> Leonardo
>>> >>>> >>
>>> >>>> >> 2014-04-22 16:03 GMT+02:00 Karl Kildén <ka...@gmail.com>:
>>> >>>> >> > +1 To the idea
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> > On 22 April 2014 15:53, Leonardo Uribe <lu...@gmail.com> wrote:
>>> >>>> >> >>
>>> >>>> >> >> Hi Thomas
>>> >>>> >> >>
>>> >>>> >> >> Yes, the idea is do something similar. The only thing we need
>>> >>>> >> >> to
>>> >>>> >> >> find
>>> >>>> >> >> out is how to do it in a way that fits better with JSF.
>>> >>>> >> >>
>>> >>>> >> >> There are different people interested in this:
>>> >>>> >> >>
>>> >>>> >> >> - Some people wants to use JSF as a template engine, because
>>> >>>> >> >> Facelets with JSF 2 Resource Handling and JSF 2.2 Resource
>>> >>>> >> >> Library
>>> >>>> >> >> Contracts can be an effective solution for server side
>>> >>>> >> >> templating.
>>> >>>> >> >>
>>> >>>> >> >> - Some people want to use a JSF component library but they need
>>> >>>> >> >> to
>>> >>>> >> >> fill some gaps, like for example create a custom component and
>>> >>>> >> >> on
>>> >>>> >> >> the way they need to create a JSON endpoint. An mixed JSF-MVC
>>> >>>> >> >> approach can be an effective solution.
>>> >>>> >> >>
>>> >>>> >> >> I think the mentioned example is just half of the solution.
>>> >>>> >> >> That's
>>> >>>> >> >> the reason why I'm gathering the use cases where this can be
>>> >>>> >> >> useful. The plan is write a prototype and discuss it, to see
>>> >>>> >> >> how
>>> >>>> >> >> far
>>> >>>> >> >> can we go with this.
>>> >>>> >> >>
>>> >>>> >> >> regards,
>>> >>>> >> >>
>>> >>>> >> >> Leonardo
>>> >>>> >> >>
>>> >>>> >> >> 2014-04-22 15:21 GMT+02:00 Thomas Andraschko
>>> >>>> >> >> <an...@gmail.com>:
>>> >>>> >> >> > Hi Leo,
>>> >>>> >> >> >
>>> >>>> >> >> > +1 for the idea.
>>> >>>> >> >> > Would it be similiar to:
>>> >>>> >> >> >
>>> >>>> >> >> >
>>> >>>> >> >> >
>>> >>>> >> >> >
>>> >>>> >> >> >
>>> >>>> >> >> > https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra
>>> >>>> >> >> > ?
>>> >>>> >> >> >
>>> >>>> >> >> > Regards,
>>> >>>> >> >> > Thomas
>>> >>>> >> >> >
>>> >>>> >> >> >
>>> >>>> >> >> > 2014-04-22 15:13 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>> >>>> >> >> >
>>> >>>> >> >> >> Hi
>>> >>>> >> >> >>
>>> >>>> >> >> >> Over the time, with the new javascript libraries out there
>>> >>>> >> >> >> that
>>> >>>> >> >> >> makes
>>> >>>> >> >> >> easier to make reliable code on the client side, there are
>>> >>>> >> >> >> more
>>> >>>> >> >> >> and
>>> >>>> >> >> >> more people interested in an approach that can take
>>> >>>> >> >> >> advantage
>>> >>>> >> >> >> of
>>> >>>> >> >> >> the good parts that JSF 2.2 already has, but without get
>>> >>>> >> >> >> into
>>> >>>> >> >> >> the
>>> >>>> >> >> >> JSF
>>> >>>> >> >> >> lifecycle complexities. It could be good if we provide a new
>>> >>>> >> >> >> module
>>> >>>> >> >> >> inside MyFaces Commons that allow to do things like in
>>> >>>> >> >> >> Spring
>>> >>>> >> >> >> MVC
>>> >>>> >> >> >> or
>>> >>>> >> >> >> JAX-RS but also integrated with JSF.
>>> >>>> >> >> >>
>>> >>>> >> >> >> For example:
>>> >>>> >> >> >>
>>> >>>> >> >> >> - Create a JSON response from a managed bean and bind it to
>>> >>>> >> >> >> a
>>> >>>> >> >> >> component
>>> >>>> >> >> >> using javascript.
>>> >>>> >> >> >> - Define REST endpoints into CDI beans.
>>> >>>> >> >> >> - Provide javascript functions that can invoke a JSF POST or
>>> >>>> >> >> >> a
>>> >>>> >> >> >> GET.
>>> >>>> >> >> >> ...
>>> >>>> >> >> >>
>>> >>>> >> >> >> I have sended already an email to the EG list related to
>>> >>>> >> >> >> this
>>> >>>> >> >> >> stuff,
>>> >>>> >> >> >> indicating some use cases where this can be useful. See:
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >>
>>> >>>> >> >> >> https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-04/message/5
>>> >>>> >> >> >>
>>> >>>> >> >> >> CASE 1: Autocomplete component
>>> >>>> >> >> >> CASE 2: Captcha component
>>> >>>> >> >> >> CASE 3: Excel/PDF/Text/CSV export
>>> >>>> >> >> >> CASE 4: REST
>>> >>>> >> >> >> CASE 5: Websockets
>>> >>>> >> >> >>
>>> >>>> >> >> >> The idea is create two things:
>>> >>>> >> >> >>
>>> >>>> >> >> >> - An extension from the JSF lifecycle.
>>> >>>> >> >> >> - A javascript library that can be called from the client
>>> >>>> >> >> >> side
>>> >>>> >> >> >> to
>>> >>>> >> >> >> invoke
>>> >>>> >> >> >> JSF on the server.
>>> >>>> >> >> >>
>>> >>>> >> >> >> The final result will look similar to an action source
>>> >>>> >> >> >> framework,
>>> >>>> >> >> >> some annotations that can be parsed to define a controller
>>> >>>> >> >> >> algorithm,
>>> >>>> >> >> >> use JSF as template framework and CDI as the model.
>>> >>>> >> >> >>
>>> >>>> >> >> >> In these moments I'm trying to imagine what can we do in
>>> >>>> >> >> >> this
>>> >>>> >> >> >> case,
>>> >>>> >> >> >> so
>>> >>>> >> >> >> any suggestion or comment about what people feel missing and
>>> >>>> >> >> >> in
>>> >>>> >> >> >> that
>>> >>>> >> >> >> sense needs to be done is most welcome.
>>> >>>> >> >> >>
>>> >>>> >> >> >> regards,
>>> >>>> >> >> >>
>>> >>>> >> >> >> Leonardo Uribe
>>> >>>> >> >> >
>>> >>>> >> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >
>>> >>>> >
>>> >>>
>>> >>>
>>> >
>>> >
>>> >
>>> >
>>
>>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Finally I have found a way to handle the POST case. Take a look at this
example, written using jQuery:
<form jsf:id="mainForm">
<input jsf:id="suggest" type="text" jsf:value="#{sayHelloBean.firstName}"/>
<script type="text/javascript">
$(document.getElementById("#{ma:clientId('suggest')}")).autocomplete({
source: function (request, response) {
$.post( "#{ma:sourceActionURL('renderOptions')}" ,
$(document.getElementById("#{ma:parentFormId()}")).serialize(),
response);
}
});
</script>
<ma:defineAction id="renderOptions"
action="#{sayHelloBean.renderJSONForAutoComplete}"
execute="@form">
</ma:defineAction>
</form>
First there is a JSF text input component, and below there are two parts: One
is the jQuery script that enables it as an autocomplete box and then there is
a component called ma:defineAction, which has the purpose to bind the
action, in this case render some JSON with the javascript using EL.
There are some EL functions:
#{ma:sourceActionURL('renderOptions') : render the URL of the action.
#{ma:clientId('suggest') : get the client id of the input component.
#{ma:parentFormId() : get the id of the closest parent form.
There is no any additional javascript function or library, so the POST is
done by jQuery.
This strategy has the following advantages/disadvantages:
* The final code can be easily reused. The EL functions help to fill the
gaps between the component tree and the client ids with the javascript, so
you can just copy/paste or encapsulate the code inside a composite
component.
* The component <ma:defineAction ...> helps to deal with the lifecycle
logic. For example, the "execute" attribute helps to define which
components need to be processed by the lifecycle before perform the action.
In this case, you can just take the value from the managed bean to render
the JSON according to the needs. The idea is also add a parameter called
<ma:actionParam> to send additional parameters in the action and process
them as f:viewParam does.
* The user has complete control about which params should be send with
each action from the javascript client. This has some risk because at the
same time JSF lose control, it is more likely the user send the wrong
parameters, or that could make the code a bit unstable if a new hidden
param for the context is added in the future.
* Since the action is defined in the view, the view must be restored
in order to process the action. That means javax.faces.ViewState and
javax.faces.ClientWindow parameters must be sent with the request. But
that also means the user should ensure the javascript code send the
params as well.
* The view state is not updated on the client, so changes done in the
component tree will not be saved and restored later. This can be a
disadvantage, but if you need to change something on the component tree
the workaround is execute the POST first and once the response has been
generated, send an ajax request to do the changes in the component tree.
This is the best we can do for the moment, to do something better it
should be done at spec level.
* If the view state is not updated on the client, if the view scope
is used by first time the view state will not hold the identifier for
the new view scope and the bean will not be saved. The solution is force
the view scope creation, maybe with a parameter in the action.
I think we can do something similar to what we used for @ViewAction in
the action. For example in #{sayHelloBean.renderJSONForAutoComplete}
we can write something like this on the bean:
public ActionResponse renderJSONForAutoComplete()
{
return new TextResponse("[\"Option A\", \"Option B\"]",
"UTF-8", "application/json");
}
or you can write it using externalContext methods if you want.
In my personal opinion, this looks good enough to continue. The next step
is write a functional prototype with some examples. It could be more ideas
to do in this part and more use cases but I consider what we have here
is enough to deal with most important or interesting cases.
Let's see what happen.
regards,
Leonardo Uribe
2014-05-15 12:43 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> 2014-05-13 20:31 GMT+02:00 Dora Rajappan <do...@yahoo.com>:
> DR> How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
> DR> excel</a>
> DR> work when ViewAction is not defined as
> DR>
> DR> @ViewAction(value="/sayhello.xhtml",
> DR> params= {
> DR> @ViewParam(name="action",
> DR> expectedValue="exportExcel")
> DR> })
> DR> public void method3(@ViewParam String param1,
> DR> @ViewParam("someOther") Integer param2)
> DR> {
> DR> but as @ViewAction("/section1/*", action="exportExcel")
> DR> Is the latter not supported now?
> DR>
>
> Good question. The idea is if you have two views on the same folder:
>
> /section1/page1.xhtml
> /section1/page2.xhtml
>
> The action will be added to both pages so it will be valid to call
>
> /section1/page1.xhtml?action=exportExcel or
> /section1/page2.xhtml?action=exportExcel.
>
> but if the page does not exists, the action will not be valid. So
> if the user calls
>
> /section1/nonexistentpage.xhtml?action=exportExcel
>
> nothing will happen.
>
> But if the user declares an action to a page that do not exists as a
> file in the path, for example:
>
> @ViewAction(value="/page_not_on_webapp_folder.xhtml",
>
> The logic will create an blank page with the view action and the
> view params declared. I have already tried it and it works well, it is
> useful in some cases when you need to include some logic before
> go into the real page, and with this you don't have to create it
> on the webapp folder. This logic is handled by a VDL wrapper.
>
> DR> facelet function getLink for action processing is not a bad idea.
>
> I think so too. It is simple to understand, but in some cases getLink(...)
> is not enough, for example when you have 2 or more parameters to
> include in the link, and you need to add some extra logic. In that
> case, a 2 step approach using a component and getLinkFrom(...)
> looks more clean and flexible. Note there is no way to add variable
> parameters with facelets EL functions, so an extended getLink(...)
> is not possible.
>
> regards,
>
> Leonardo
>
>> On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe <lu...@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="search"/>
>> <script type="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 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):
>>
>> <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
>>
>> and
>>
>> <ma:defineLink id="mylink">
>> <f:param name="action" value="renderMessage"/>
>> </ma:defineLink>
>>
>> <a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
>>
>> #{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:
>>
>> <form action="#{ma:encodeActionURL()}"
>> method="post"
>> enctype="application/x-www-form-urlencoded">
>> ....
>> </form>
>>
>> #{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 <lu...@gmail.com>:
>>> 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
>>
>>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2014-05-13 20:31 GMT+02:00 Dora Rajappan <do...@yahoo.com>:
DR> How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
DR> excel</a>
DR> work when ViewAction is not defined as
DR>
DR> @ViewAction(value="/sayhello.xhtml",
DR> params= {
DR> @ViewParam(name="action",
DR> expectedValue="exportExcel")
DR> })
DR> public void method3(@ViewParam String param1,
DR> @ViewParam("someOther") Integer param2)
DR> {
DR> but as @ViewAction("/section1/*", action="exportExcel")
DR> Is the latter not supported now?
DR>
Good question. The idea is if you have two views on the same folder:
/section1/page1.xhtml
/section1/page2.xhtml
The action will be added to both pages so it will be valid to call
/section1/page1.xhtml?action=exportExcel or
/section1/page2.xhtml?action=exportExcel.
but if the page does not exists, the action will not be valid. So
if the user calls
/section1/nonexistentpage.xhtml?action=exportExcel
nothing will happen.
But if the user declares an action to a page that do not exists as a
file in the path, for example:
@ViewAction(value="/page_not_on_webapp_folder.xhtml",
The logic will create an blank page with the view action and the
view params declared. I have already tried it and it works well, it is
useful in some cases when you need to include some logic before
go into the real page, and with this you don't have to create it
on the webapp folder. This logic is handled by a VDL wrapper.
DR> facelet function getLink for action processing is not a bad idea.
I think so too. It is simple to understand, but in some cases getLink(...)
is not enough, for example when you have 2 or more parameters to
include in the link, and you need to add some extra logic. In that
case, a 2 step approach using a component and getLinkFrom(...)
looks more clean and flexible. Note there is no way to add variable
parameters with facelets EL functions, so an extended getLink(...)
is not possible.
regards,
Leonardo
> On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe <lu...@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="search"/>
> <script type="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 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):
>
> <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
>
> and
>
> <ma:defineLink id="mylink">
> <f:param name="action" value="renderMessage"/>
> </ma:defineLink>
>
> <a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
>
> #{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:
>
> <form action="#{ma:encodeActionURL()}"
> method="post"
> enctype="application/x-www-form-urlencoded">
> ....
> </form>
>
> #{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 <lu...@gmail.com>:
>> 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
>
>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Dora Rajappan <do...@yahoo.com>.
Examples are good enough. Rest and websockets are not yet implemented.
On Wednesday, May 28, 2014 9:39 PM, Kito Mann <ki...@virtua.com> wrote:
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://blogs.jsfcentral.com/JSFNewscast/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 <lu...@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 <lu...@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 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 <do...@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 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 <lu...@gmail.com> 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 <do...@yahoo.com>:
>>>> <a href="#{ma:getLink('/section1/mypage?action=exportExcel')}">Export
>>>> excel</a> 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
>>>> <do...@yahoo.com>
>>>> wrote:
>>>> How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
>>>> excel</a>
>>>> 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 <lu...@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="search"/>
>>>> <script type="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 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):
>>>>
>>>> <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
>>>>
>>>> and
>>>>
>>>> <ma:defineLink id="mylink">
>>>> <f:param name="action" value="renderMessage"/>
>>>> </ma:defineLink>
>>>>
>>>> <a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
>>>>
>>>> #{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:
>>>>
>>>> <form action="#{ma:encodeActionURL()}"
>>>> method="post"
>>>> enctype="application/x-www-form-urlencoded">
>>>> ....
>>>> </form>
>>>>
>>>> #{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 <lu...@gmail.com>:
>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Kito Mann <ki...@virtua.com>.
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
<http://blogs.jsfcentral.com/JSFNewscast/>ww.enterprisejavanews.com
<http://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 <lu...@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 <lu...@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 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 <do...@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 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 <lu...@gmail.com>
> 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 <do...@yahoo.com>:
> >>> <a href="#{ma:getLink('/section1/mypage?action=exportExcel')}">Export
> >>> excel</a> 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
> >>> <do...@yahoo.com>
> >>> wrote:
> >>> How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
> >>> excel</a>
> >>> 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 <lu...@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="search"/>
> >>> <script type="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 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):
> >>>
> >>> <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
> excel</a>
> >>>
> >>> and
> >>>
> >>> <ma:defineLink id="mylink">
> >>> <f:param name="action" value="renderMessage"/>
> >>> </ma:defineLink>
> >>>
> >>> <a href="#{ma:getLinkFrom('mylink')}">Render url from EL
> expression</a>
> >>>
> >>> #{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:
> >>>
> >>> <form action="#{ma:encodeActionURL()}"
> >>> method="post"
> >>> enctype="application/x-www-form-urlencoded">
> >>> ....
> >>> </form>
> >>>
> >>> #{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 <lu...@gmail.com>:
> >>>> 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
> >>>
> >>>
> >>>
> >>>
> >>
> >>
>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <lu...@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 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 <do...@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 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 <lu...@gmail.com> 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 <do...@yahoo.com>:
>>> <a href="#{ma:getLink('/section1/mypage?action=exportExcel')}">Export
>>> excel</a> 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
>>> <do...@yahoo.com>
>>> wrote:
>>> How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
>>> excel</a>
>>> 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 <lu...@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="search"/>
>>> <script type="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 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):
>>>
>>> <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
>>>
>>> and
>>>
>>> <ma:defineLink id="mylink">
>>> <f:param name="action" value="renderMessage"/>
>>> </ma:defineLink>
>>>
>>> <a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
>>>
>>> #{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:
>>>
>>> <form action="#{ma:encodeActionURL()}"
>>> method="post"
>>> enctype="application/x-www-form-urlencoded">
>>> ....
>>> </form>
>>>
>>> #{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 <lu...@gmail.com>:
>>>> 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
>>>
>>>
>>>
>>>
>>
>>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Leonardo Uribe <lu...@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 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 <do...@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 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 <lu...@gmail.com> 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 <do...@yahoo.com>:
>> <a href="#{ma:getLink('/section1/mypage?action=exportExcel')}">Export
>> excel</a> 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
>> <do...@yahoo.com>
>> wrote:
>> How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
>> excel</a>
>> 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 <lu...@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="search"/>
>> <script type="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 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):
>>
>> <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
>>
>> and
>>
>> <ma:defineLink id="mylink">
>> <f:param name="action" value="renderMessage"/>
>> </ma:defineLink>
>>
>> <a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
>>
>> #{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:
>>
>> <form action="#{ma:encodeActionURL()}"
>> method="post"
>> enctype="application/x-www-form-urlencoded">
>> ....
>> </form>
>>
>> #{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 <lu...@gmail.com>:
>>> 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
>>
>>
>>
>>
>
>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Dora Rajappan <do...@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 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 <lu...@gmail.com> 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 <do...@yahoo.com>:
> <a href="#{ma:getLink('/section1/mypage?action=exportExcel')}">Export
> excel</a> 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 <do...@yahoo.com>
> wrote:
> How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
> excel</a>
> 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 <lu...@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="search"/>
> <script type="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 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):
>
> <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
>
> and
>
> <ma:defineLink id="mylink">
> <f:param name="action" value="renderMessage"/>
> </ma:defineLink>
>
> <a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
>
> #{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:
>
> <form action="#{ma:encodeActionURL()}"
> method="post"
> enctype="application/x-www-form-urlencoded">
> ....
> </form>
>
> #{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 <lu...@gmail.com>:
>> 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
>
>
>
>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <do...@yahoo.com>:
> <a href="#{ma:getLink('/section1/mypage?action=exportExcel')}">Export
> excel</a> 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 <do...@yahoo.com>
> wrote:
> How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export
> excel</a>
> 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 <lu...@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="search"/>
> <script type="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 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):
>
> <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
>
> and
>
> <ma:defineLink id="mylink">
> <f:param name="action" value="renderMessage"/>
> </ma:defineLink>
>
> <a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
>
> #{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:
>
> <form action="#{ma:encodeActionURL()}"
> method="post"
> enctype="application/x-www-form-urlencoded">
> ....
> </form>
>
> #{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 <lu...@gmail.com>:
>> 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
>
>
>
>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Dora Rajappan <do...@yahoo.com>.
<a href="#{ma:getLink('/section1/mypage?action=exportExcel')}">Export excel</a> 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 <do...@yahoo.com> wrote:
How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
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 <lu...@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="search"/>
<script type="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 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):
<a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
and
<ma:defineLink id="mylink">
<f:param name="action" value="renderMessage"/>
</ma:defineLink>
<a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
#{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:
<form action="#{ma:encodeActionURL()}"
method="post"
enctype="application/x-www-form-urlencoded">
....
</form>
#{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 <lu...@gmail.com>:
> 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
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Dora Rajappan <do...@yahoo.com>.
How will <a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
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 <lu...@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="search"/>
<script type="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 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):
<a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
and
<ma:defineLink id="mylink">
<f:param name="action" value="renderMessage"/>
</ma:defineLink>
<a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
#{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:
<form action="#{ma:encodeActionURL()}"
method="post"
enctype="application/x-www-form-urlencoded">
....
</form>
#{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 <lu...@gmail.com>:
> 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
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Leonardo Uribe <lu...@gmail.com>.
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="search"/>
<script type="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 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):
<a href="#{ma:getLink('mypage?action=exportExcel')}">Export excel</a>
and
<ma:defineLink id="mylink">
<f:param name="action" value="renderMessage"/>
</ma:defineLink>
<a href="#{ma:getLinkFrom('mylink')}">Render url from EL expression</a>
#{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:
<form action="#{ma:encodeActionURL()}"
method="post"
enctype="application/x-www-form-urlencoded">
....
</form>
#{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 <lu...@gmail.com>:
> 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
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Leonardo Uribe <lu...@gmail.com>.
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
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Thomas Andraschko <an...@gmail.com>.
@Dora
I don't think that such a early prototype from Mojarra will automatically
be a spec part... ;)
2014-05-04 21:15 GMT+02:00 Thomas Andraschko <an...@gmail.com>:
> Hi Leo,
>
> AFAIR now, your solutions seems to be just a replacement for f:viewAction
> + allow different handlers via URL parameters.
> Its sound really lightweight and easy actually :)
> Does it cover all our requirements from the earlier mails?
>
> 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")
> })
>
> Regards,
> Thomas
>
>
>
> 2014-05-02 18:47 GMT+02:00 Dora Rajappan <do...@yahoo.com>:
>
> Hi,
>>
>> According to Thomas mojarra has a prototype mapping FasesServlet as
>> action servlet with lifecycle id as param .
>> So this implementation will be part spec and will go to myfaces project!
>>
>> I think the f:viewParam and f:viewAction is not used very much. It gets
>> executed when the page is loaded.
>>
>> Regarding Bean having RequestMapping and returning a view is same with
>> faces-config mapping. And if its partial its like ajax. Good thing is the
>> flexibility is added to the Bean.
>>
>> Its different when its executing a lifecycle phase which is good to
>> support and new and may go to myfaces commons project.
>>
>> Regards,
>> Dora Rajappan.
>>
>> On Wednesday, April 30, 2014 8:58 PM, Leonardo Uribe <lu...@gmail.com>
>> wrote:
>> Hi
>>
>> After doing some attempts I found that a syntax like the one in
>> spring mvc @RequestMapping fits better:
>>
>> @ViewAction(value="/sayhello.xhtml", params="action=exportExcel")
>> public void method3()
>> {
>>
>> Then in the page you can write something like this:
>>
>> <h:link outcome="sayhello" value="Export to excel" target="_blank">
>> <f:param name="action" value="exportExcel"/>
>> </h:link>
>>
>> This is nice because the url includes the client window id
>> automatically in the action.
>>
>> @RequestMapping propose these fields for matching:
>>
>> String[] headers
>> RequestMethod[] method
>> String[] params
>> String[] consumes
>> String[] produces
>>
>> But from JSF perspective, the only interesting to add is params. To
>> restrict
>> the action in case of a POST, we could add a custom param like
>>
>> boolean processOnPostback
>>
>> or something like that.
>>
>> Theoretically, f:viewAction has "rendered" property to restrict the case
>> when the action is executed or not, but it is easier to understand the
>> annotation syntax to restrict the cases where the action should be
>> executed.
>>
>> In this way, we are adding what is useful and discarding the remaining
>> stuff that is just noise for JSF. If anyone feels add something extra can
>> be useful, this is a good moment to say it.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2014-04-30 14:14 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>> > Hi Thomas
>> >
>> > TA> cool!
>> > TA>
>> > TA> Your ViewAction currently returns a string. Is it just a "html"
>> string?
>> > TA>
>> >
>> > Since @ViewAction resembles f:viewAction the string is the outcome that
>> is used
>> > to navigate on invoke application phase. It triggers a navigation. But
>> we can
>> > do something else, in the wrapper of the method.
>> >
>> > TA> What about rendering a view/rewrite url like ->
>> > TA> @ViewAction("/actions/registragion/start")
>> > TA> public void View myAction(
>> > TA>
>> > TA> return new View("/views/registration/startRegistration.xhtml");
>> > TA> }
>> > TA>
>> >
>> > I think it is another different case, that probably will require
>> > another annotation. It is something confusing at first view, but
>> > I'll try to clarify it here.
>> >
>> > In an action oriented framework, the path is used to indicate
>> > the specific action. For example, /actions/registragion/start is a
>> > defined point, so as soon as the user activates it, usually
>> > clicking on the related link, something happens in the action
>> > and then the control pass to the view.
>> >
>> > But in a framework like JSF, the control moves from page to
>> > page. In other words, it is page centric. So, instead to move
>> > into a some intermediate state, the control should go directly to
>> > the page and after that, all actions done by components will be
>> > handled by the page itself. For example, a form submit is always
>> > send as an "action" of the page with these parameters:
>> >
>> > javax.faces.ViewState
>> > [form_clientId]_SUBMIT
>> > ....
>> >
>> > Then, decode() method of the form check which form was
>> > submitted and process the necessary operations.
>> >
>> > Now, let's see what happen with an action oriented framework,
>> > for example Spring MVC in a login form (taken from the
>> > performance comparison, removing the unnecessary parts):
>> >
>> > @Controller
>> > @Scope("request")
>> > @RequestMapping(value = "/home")
>> > public class LoginController
>> > {
>> >
>> > @RequestMapping(method = RequestMethod.GET)
>> > public String home(Map model)
>> > {
>> > model.put("loginForm", new LoginForm());
>> > return "home";
>> > }
>> > /*.. more code goes here..*/
>> >
>> > This is what is on the jsp:
>> >
>> > <form:form method="post" action="home.do" commandName="loginForm">
>> >
>> > The model here is different. The control belongs to LoginController,
>> > the page has not an associated "implicit" controller, and in the page
>> > you must write some lines to give back the control to the controller.
>> >
>> >
>> > Do things like that is a complete nonsense for JSF, because that's
>> > the kind of code that cause maintenance problems.
>> >
>> > There are two options:
>> >
>> > 1. Put a front controller that sends the control to the bean and then
>> > in the bean you can decide which page takes the control. From that
>> > point the control does not get back to the bean, and the inner
>> > controller (jsf lifecycle) takes care of form submission and the
>> > remaining code. A new annotation is required.
>> >
>> > or
>> >
>> > 2. Define an special query parameter with the action, so the action is
>> > activated based on the value provided in that field.
>> >
>> > For example:
>> >
>> > @ViewAction("/section1/*", actionEvent="getList")
>> > public void method2()
>> > {
>> > FacesContext facesContext = FacesContext.getCurrentInstance();
>> > /* .... generate custom response ... */
>> > facesContext.responseComplete()
>> > }
>> >
>> > or something more simplified
>> >
>> > @ViewAction("/section1/*", actionEvent="getList")
>> > public Content method2()
>> > {
>> > return new Content("a, b, c");
>> > }
>> >
>> > and do the necessary stuff on the background.
>> >
>> > I feel inclined to use option 2, because the front controller approach
>> > clash with some basic concepts of JSF.
>> >
>> > TA> Will it also cover Excel/PDF... export?
>> >
>> > Yes, I think so, but we need to try. Really with the discussion we
>> > are trying to understand what's going on and how to adapt it into
>> > JSF.
>> >
>> > If you take a look, the discussion is leading us to something
>> > "in the middle". Does it work? does it solve the problem found in JSF?
>> > That's something we need to find out.
>> >
>> > regards,
>> >
>> > Leonardo Uribe
>> >
>> >>
>> >> Regards,
>> >> Thomas
>> >>
>> >>
>> >>
>> >> 2014-04-29 20:02 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>> >>
>> >>> Hi
>> >>>
>> >>> I have done a fast prototype, just to check how things could work and
>> how
>> >>> the
>> >>> pieces can be grouped together, and there are some interesting ideas
>> that
>> >>> are
>> >>> worth to consider.
>> >>>
>> >>> In JSF 2, when f:viewParam was added, some logic was added to create
>> the
>> >>> view
>> >>> in two steps: first you create the view metadata, where f:viewParam
>> and
>> >>> now
>> >>> f:viewAction lives and then you "fill" the view, executing facelets
>> >>> algorithm
>> >>> again and in that way create the full component hierarchy.
>> >>>
>> >>> One idea it came to my mind is create a ViewDeclarationLanguage
>> wrapper
>> >>> and
>> >>> override getViewMetadata(...) method to inject a f:viewAction
>> component
>> >>> according to the definition in the CDI bean. For example:
>> >>>
>> >>> @Named("sayHelloBean")
>> >>> @ActionController
>> >>> @RequestScoped
>> >>> public class SayHelloBean
>> >>> {
>> >>>
>> >>> @ViewAction("/section1/*")
>> >>> public String method2()
>> >>> {
>> >>>
>> >>> That makes all views that match with the pattern provided to have an
>> extra
>> >>> f:viewAction component, with the existing rules that apply for them.
>> You
>> >>> can
>> >>> also imagine something like this:
>> >>>
>> >>> @ViewAction("/section1/*")
>> >>> public String method2(@ViewParam String param1)
>> >>>
>> >>> What we are saying with the syntax is: "... all views that are are
>> part of
>> >>> section1 will have a ViewAction listener and will have a view param
>> called
>> >>> param1. ...".
>> >>>
>> >>> This approach the following advantages:
>> >>>
>> >>> - Provide a way to define view actions without override the html
>> markup in
>> >>> every top level template page.
>> >>> - It reuse the existing logic for JSF view action, so it is easy to
>> >>> understand
>> >>> for the users.
>> >>> - It can be included in JSF 2.2.
>> >>> - JSF is still in control of the navigation at all times, because
>> there is
>> >>> no
>> >>> Front Controller.
>> >>> - The context will be automatically managed by JSF.
>> >>>
>> >>> but also has the following limitations:
>> >>>
>> >>> - With an action source framework it is possible to define a wide
>> range of
>> >>> conditions to activate the action. For example if the request is a
>> GET or
>> >>> a
>> >>> POST, of if it sends some specific header, even take parameters from
>> the
>> >>> path.
>> >>> In this solution, the viewId is used for pattern maching and only
>> >>> considers
>> >>> query parameters.
>> >>> - It bounds the action to a view, so if there is no view, there is no
>> >>> action.
>> >>>
>> >>>
>> >>> And we finally get to the central point of discussion: How much
>> >>> flexibility we
>> >>> really need or the users want to define view actions?
>> >>>
>> >>> Remember the first lines in JSF spec:
>> >>>
>> >>> "... JSF’s core architecture is designed to be independent of specific
>> >>> protocols and markup. ..."
>> >>>
>> >>> Now take a look for example about what JAX-RS spec says about:
>> >>>
>> >>> "... The following are the goals of the API: POJO-based, HTTP-centric,
>> >>> Format independence, Container independence, Inclusion in Java EE ..."
>> >>>
>> >>> In that sense, all other features provided by action source
>> frameworks are
>> >>> just useless for JSF, besides include a way to declare view actions
>> into
>> >>> CDI beans.
>> >>>
>> >>> If we review the related requeriments Thomas Andraschko provided:
>> >>>
>> >>> 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
>> >>>
>> >>> I think with the approach proposed we can comply with the
>> requirements.
>> >>>
>> >>> Maybe we should forget about the rest, and focus our efforts in
>> explore
>> >>> this approach.
>> >>>
>> >>> DR>> +1 for the idea. Are you going to have two sets of release jars
>> with
>> >>> DR>> and without extensions ? Is it going to be a different project?
>> >>>
>> >>> It is still a proposal (please read the subject of the message), so it
>> >>> is too early to say something about.
>> >>>
>> >>> DR>> Spring MVC beans can be configured to be accessed from the
>> >>> ManagedBeans.
>> >>> DR>> You are talking about the spring beans integration in the jsf
>> >>> elements?
>> >>>
>> >>> The mail is clear in this. The idea is explore how to do things like
>> with
>> >>> an action source framework, but in JSF 2.2 / CDI, probably writing a
>> CDI
>> >>> extension. There is no integration code with a third party framework,
>> the
>> >>> idea is found new ways to solve existing problems.
>> >>>
>> >>> regards,
>> >>>
>> >>> Leonardo Uribe
>> >>>
>> >>> 2014-04-29 18:32 GMT+02:00 Dora Rajappan <do...@yahoo.com>:
>> >>> > +1 for the idea. Are you going to have two sets of release jars
>> with
>> >>> > and
>> >>> > without extensions ? Is it going to be a different project?
>> >>> >
>> >>> > Spring MVC beans can be configured to be accessed from the
>> ManagedBeans.
>> >>> > You
>> >>> > are talking about the spring beans integration in the jsf elements?
>> >>> >
>> >>> > Regards,
>> >>> > Dora Rajappan.
>> >>> > On Friday, April 25, 2014 7:03 PM, Thomas Andraschko
>> >>> > <an...@gmail.com> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > sounds good enough for a first prototype -> +1
>> >>> >
>> >>> > Regards,
>> >>> > Thomas
>> >>> >
>> >>> >
>> >>> > 2014-04-25 15:23 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>> >>> >
>> >>> > Hi
>> >>> >
>> >>> > There are different things we would like to include in this module.
>> For
>> >>> > now, let's focus on rethink how "actions" should be processed in
>> JSF.
>> >>> >
>> >>> > To make things easier, let's start with a comparison between
>> >>> > f:viewAction
>> >>> > and
>> >>> > a solution that involves a front controller and some actions defines
>> >>> > using
>> >>> > annotations in a CDI bean.
>> >>> >
>> >>> > In the first case, the developer defines the action in the page
>> using a
>> >>> > tag:
>> >>> >
>> >>> > SOLUTION 1:
>> >>> >
>> >>> > <f:metadata>
>> >>> > <f:viewParam name="id" value="#{personPage.id}"/>
>> >>> > <f:viewAction action="#{personPage.loadPerson}"/>
>> >>> > </f:metadata>
>> >>> >
>> >>> > The alternative approach to discuss here is use a managed bean that
>> >>> > defines
>> >>> > a path that will work as an starting point:
>> >>> >
>> >>> > SOLUTION 2:
>> >>> >
>> >>> > @Named("myBean")
>> >>> > @ActionController
>> >>> > @RequestScoped
>> >>> > public class MyBean
>> >>> > {
>> >>> > @Action("/actions/do/something")
>> >>> > // userId param with automatic converter lookup
>> >>> > public View myAction()
>> >>> > {
>> >>> > return new
>> View("/views/registration/startRegistration.xhtml");
>> >>> > }
>> >>> > }
>> >>> >
>> >>> > There are multiple differences between both solutions:
>> >>> >
>> >>> > * <f:viewAction> requires a view to be defined, so when the
>> >>> > f:viewAction is
>> >>> > processed, there is a FacesContext, a client window set (if any)
>> and
>> >>> > there
>> >>> > is a view context too. With the annotations there is no
>> associated
>> >>> > view,
>> >>> > so it can't be a valid UIViewRoot at that moment.
>> >>> >
>> >>> > * The annotation approach allows navigation without being in a
>> view.
>> >>> > With
>> >>> > f:viewAction it is possible to cause a navigation like with a
>> >>> > h:commandButton.
>> >>> >
>> >>> > * f:viewAction still requires a managed bean to handle the action.
>> The
>> >>> > syntax
>> >>> > using annotations is more compact, because requires only the
>> managed
>> >>> > bean.
>> >>> >
>> >>> > * f:viewAction is activated every time the page is loaded by first
>> time
>> >>> > (in practice, every time a GET is processed), but with the
>> >>> > annotations
>> >>> > it is necessay to define the conditions under the action is
>> >>> > activated.
>> >>> >
>> >>> > I think f:viewAction and the annotation approach are different
>> things,
>> >>> > even
>> >>> > if they share some similarities.
>> >>> >
>> >>> > JSF has been always a "page centric" framework. The developer write
>> some
>> >>> > pages, but to define the navigation, the developer has the option of
>> >>> > write
>> >>> > some navigation rules or he/she can also use an implicit navigation.
>> >>> >
>> >>> > f:viewAction design fits really well with JSF, as long as you are
>> >>> > dealing
>> >>> > with
>> >>> > "view actions". But in some cases, the action doesn't have any
>> >>> > relationship
>> >>> > with any view. That's the case where an action defined into a
>> managed
>> >>> > bean
>> >>> > has
>> >>> > sense.
>> >>> >
>> >>> > For example, when the user want to verify a condition for all pages
>> >>> > inside
>> >>> > a folder. If the condition is not valid, an specified page should be
>> >>> > rendered.
>> >>> > Some solutions for that problem are:
>> >>> >
>> >>> > 1. Create a filter and handle the logic there
>> >>> > 2. Create a ViewHandler wrapper, override createView(...) and
>> handle the
>> >>> > logic
>> >>> > there.
>> >>> >
>> >>> > But it would be nice to have something like this:
>> >>> >
>> >>> > @Named("myBean")
>> >>> > @ActionController
>> >>> > @RequestScoped
>> >>> > public class CheckUserBean
>> >>> > {
>> >>> > @Priority(Priorities.USER)
>> >>> > @Action("/registration/*")
>> >>> > // userId param with automatic converter lookup
>> >>> > public View myAction()
>> >>> > {
>> >>> > if (the current flow is not active)
>> >>> > {
>> >>> > return new Navigation("registration");
>> >>> > }
>> >>> > // Otherwise continue to the expected page
>> >>> > return null;
>> >>> > }
>> >>> > }
>> >>> >
>> >>> > In this case we have an action that is executed based on a pattern,
>> in a
>> >>> > specified moment, for a set of pages, and that could cause a
>> navigation
>> >>> > to another page or could not affect the navigation and JSF lifecycle
>> >>> > takes
>> >>> > place as usual.
>> >>> >
>> >>> > The other kind of action proposed:
>> >>> >
>> >>> > @Action("/actions/do/something")
>> >>> > // userId param with automatic converter lookup
>> >>> > public View myAction()
>> >>> > {
>> >>> > return new
>> View("/views/registration/startRegistration.xhtml");
>> >>> > }
>> >>> >
>> >>> > It can be something like this too:
>> >>> >
>> >>> > @Action("/actions/do/something")
>> >>> > // userId param with automatic converter lookup
>> >>> > public void myAction()
>> >>> > {
>> >>> > FacesContext facesContext =
>> FacesContext.getCurrentInstance();
>> >>> >
>> >>> > /* ... generate text, pdf, xml or whatever ...*/
>> >>> >
>> >>> > facesContext.responseComplete();
>> >>> > }
>> >>> >
>> >>> > the responseComplete() cause the lifecycle to be skipped.
>> >>> >
>> >>> > I think these ideas does not overlap or replace the utility of
>> >>> > f:viewAction,
>> >>> > and instead the aim is solve a different problem. I'll try to make a
>> >>> > prototype with the ideas exposed here. I have some more ideas for
>> the
>> >>> > other
>> >>> > requeriments we have, but for now the idea is focus on what looks
>> more
>> >>> > important or useful.
>> >>> >
>> >>> > Suggestions are welcome.
>> >>> >
>> >>> > regards,
>> >>> >
>> >>> > Leonardo
>> >>> >
>> >>> > 2014-04-23 15:45 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>> >>> >> Hi
>> >>> >>
>> >>> >> 2014-04-23 14:16 GMT+02:00 Thomas Andraschko
>> >>> >> <an...@gmail.com>:
>> >>> >>> LU>> 4) Allow action rendering in in a normal lifecycle:
>> >>> >>> LU>>
>> >>> >>> LU>> <ui:renderAction action="#{myBrean.myAction(
>> >>> >>> LU>bean.value, 1)}" />
>> >>> >>> LU>>
>> >>> >>> LU>
>> >>> >>> LU>Could you please describe better this case? So you execute the
>> >>> >>> action,
>> >>> >>> LU> but the lifecycle goes on as usual?
>> >>> >>
>> >>> >>
>> >>> >> TA> It's just a component, which renders the returned html string
>> from
>> >>> >> the
>> >>> >> TA> action into the ResponseWriter.
>> >>> >> TA> Something like a include for the action return value.
>> >>> >> TA>
>> >>> >> TA>
>> >>> >> TA> This would be also helpful if we combine facelet rendering +
>> >>> >> actions.
>> >>> >> TA> In ASP.NET MVC, the action could also return a
>> View/PartialView:
>> >>> >> TA>
>> >>> >> TA>
>> >>> >> TA>> @Named("myBean")
>> >>> >> TA>> @RequestScoped
>> >>> >> TA>> public class MyBean {
>> >>> >> TA>> @Action
>> >>> >> TA>> // userId param with automatic converter lookup
>> >>> >> TA>> public PartialView myAction(String myUrlParam, User
>> >>> >> userId)
>> >>> >> {
>> >>> >> TA>> return new
>> >>> >> TA>> PartialView("/META-INF/mylib/myincludes/myfile.xhtml");
>> >>> >> TA>> }
>> >>> >> TA>> }
>> >>> >> TA>
>> >>> >> TA> It would load the xhtml, renders the xhtml and return the
>> rendered
>> >>> >> html
>> >>> >> TA> string - called via ui:renderAction or via URL.
>> >>> >> TA>
>> >>> >>
>> >>> >> So you mean use JSF as a template engine to render some html
>> fragments.
>> >>> >> I think it can be done.
>> >>> >>
>> >>> >> This feature is something controversial, because it could be used
>> >>> >> wrongly.
>> >>> >> For example, you have a page fragment and you want to update it
>> using
>> >>> >> this stuff and some javascript. Since you are bypassing JSF, the
>> >>> >> results
>> >>> >> can be unexpected, because JSF is no longer in control of the view
>> >>> >> state
>> >>> >> anymore. The right way is affect the component state (or the model
>> >>> >> state),
>> >>> >> so when it is rendered it gets updated. The best way to do it, is
>> with
>> >>> >> ajax,
>> >>> >> because ajax knows about the relationship between different
>> components.
>> >>> >>
>> >>> >> Also, you could have situations when the ids are not correctly
>> >>> >> generated,
>> >>> >> and at the end have duplicate ids. Again, the solution is add or
>> remove
>> >>> >> the
>> >>> >> component from the component tree programmatically, so JSF can have
>> >>> >> the change to deal with this problem properly.
>> >>> >>
>> >>> >> More than a PartialView, I think in this case JSF is used as a raw
>> html
>> >>> >> or
>> >>> >> xml generator. For example, the html in this case could be a
>> formatted
>> >>> >> message and so on.
>> >>> >>
>> >>> >> I think it is better if we avoid the term "PartialView" and
>> instead we
>> >>> >> provide
>> >>> >> something more abstract like "Response" or "MarkupFragment" or
>> >>> >> something like that. Something that indicates that this is not
>> part of
>> >>> >> the
>> >>> >> view itself, and instead is part of the "client state".
>> >>> >>
>> >>> >>>
>> >>> >>>
>> >>> >>> I think we could also completely rebuild the GET functionality for
>> >>> >>> actions.
>> >>> >>> Maybe could just render the startRegistration.xhtml via a normal
>> JSF
>> >>> >>> lifecycle after the action call.
>> >>> >>>
>> >>> >>>> @Named("myBean")
>> >>> >>>> @RequestScoped
>> >>> >>>> public class MyBean {
>> >>> >>>> @Action(mapping = "/actions/do/something")
>> >>> >>>
>> >>> >>>> // userId param with automatic converter lookup
>> >>> >>>> public View myAction() {
>> >>> >>>> return new
>> >>> >>>> View("/views/registration/startRegistration.xhtml");
>> >>> >>>> }
>> >>> >>>> }
>> >>> >>>
>> >>> >>
>> >>> >> It can be done. In fact, it works like a url rewriting. Maybe it is
>> >>> >> more
>> >>> >> straighforward for users after all, because with f:viewAction, you
>> >>> >> can't
>> >>> >> control the page, but with this, you can add some logic before the
>> >>> >> final page is processed, like for example a conditional and so on.
>> >>> >>
>> >>> >>> Just some ideas for a more complete add-on.
>> >>> >>> That would cover the "view" and "controller". The "model" are
>> actually
>> >>> >>> the
>> >>> >>> beans via EL.
>> >>> >>>
>> >>> >>> Don't know if it really fits JSF or if there are better concepts
>> - but
>> >>> >>> that
>> >>> >>> are almost all core features of ASP.NET MVC.
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >> I think what we are doing here instead is take the best we found
>> from
>> >>> >> the
>> >>> >> things we know that works. The challenge is integrate in a coherent
>> >>> >> way.
>> >>> >>
>> >>> >> For example, JSF as a component oriented framework has the concept
>> >>> >> of clientIds associated with components. This is very helpful when
>> you
>> >>> >> move code from one place to another, because the generated ids on
>> >>> >> the client side are updated properly. In an action oriented
>> framework,
>> >>> >> that's
>> >>> >> a complete mess. The idea is preserve the JSF abstraction, that
>> means
>> >>> >> components that can be assembled in a hierarchical way, and that
>> also
>> >>> >> means this tree has a similar structure on the client.
>> >>> >>
>> >>> >> We can find workarounds. For example, bind the html generation to
>> >>> >> a component, so we say "... generate an html fragment, but keep in
>> mind
>> >>> >> that chunk will be used in this component or a component with this
>> >>> >> client id ..." So, the fragment is encapsulated in a jsf component
>> that
>> >>> >> implements NamingContainer and generates the specified clientId.
>> >>> >> That could work. But I suppose it should be MyFaces Core
>> implementation
>> >>> >> specific, because we need to indicate to facelets the way how the
>> ids
>> >>> >> should be generated.
>> >>> >>
>> >>> >> regards,
>> >>> >>
>> >>> >> Leonardo Uribe
>> >>> >>
>> >>> >>>
>> >>> >>> 2014-04-23 13:40 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>> >>> >>>
>> >>> >>>> Hi
>> >>> >>>>
>> >>> >>>> 2014-04-23 11:54 GMT+02:00 Thomas Andraschko
>> >>> >>>> <an...@gmail.com>:
>> >>> >>>> TA> Hi,
>> >>> >>>> TA>
>> >>> >>>> TA> the most important question for me is actually:
>> >>> >>>> TA>
>> >>> >>>> TA> 1) How much should we really mix actions with facelets
>> rendering?
>> >>> >>>> TA>
>> >>> >>>> TA> There are soooo many things to consider. As you already said
>> in
>> >>> >>>> your
>> >>> >>>> specs
>> >>> >>>> TA> post: viewstate, windowid, viewscoped, ....
>> >>> >>>> TA>
>> >>> >>>>
>> >>> >>>> I think the best way to deal with facelets rendering is use the
>> >>> >>>> standard
>> >>> >>>> ajax.
>> >>> >>>> I know in an action source framework people have to do the ajax
>> stuff
>> >>> >>>> "by hand", which means use the template framework to calculate a
>> >>> >>>> fragment
>> >>> >>>> of the response. That's a step back.
>> >>> >>>>
>> >>> >>>> Instead, this is for the case when you have a page in the client
>> and
>> >>> >>>> you
>> >>> >>>> need
>> >>> >>>> to communicate with the server to get some information, but the
>> page
>> >>> >>>> structure
>> >>> >>>> does not change. For example, an autocomplete component or a
>> >>> >>>> datatable
>> >>> >>>> component. In that case, you only need the data usually in json
>> >>> >>>> format,
>> >>> >>>> and
>> >>> >>>> there is a javascript already in place to deal with that data and
>> >>> >>>> change
>> >>> >>>> the
>> >>> >>>> state of the client.
>> >>> >>>>
>> >>> >>>> The point is deal with the context in general. So if you send a
>> POST
>> >>> >>>> from
>> >>> >>>> the
>> >>> >>>> client, and you provide the windowid and the viewstate token, it
>> >>> >>>> should
>> >>> >>>> be
>> >>> >>>> processed, and the response should update the viewstate if
>> necessary.
>> >>> >>>> That's why we need some javascript on the client to wire things
>> up.
>> >>> >>>>
>> >>> >>>> It could be possible a complex case, where we need a json
>> response
>> >>> >>>> but
>> >>> >>>> the response triggers an ajax update from the server. It can be
>> done,
>> >>> >>>> with
>> >>> >>>> some javascript code.
>> >>> >>>>
>> >>> >>>> >
>> >>> >>>> > For me the most important things are actually:
>> >>> >>>> >
>> >>> >>>> > 1) possibility to use a normal JSF lifecycle for the first GET
>> >>> >>>> > request
>> >>> >>>>
>> >>> >>>> I agree with you, because in the first request you are just
>> building
>> >>> >>>> the
>> >>> >>>> view,
>> >>> >>>> no special things there.
>> >>> >>>>
>> >>> >>>> > 2) allow action handling and custom response for POST actions
>> >>> >>>>
>> >>> >>>> Yes.
>> >>> >>>>
>> >>> >>>> > 3) normal action handling like in asp.net MVC + a EL util
>> function
>> >>> >>>> > to
>> >>> >>>> > generate the action URL
>> >>> >>>> >
>> >>> >>>> > $('#input').autocomplete({
>> >>> >>>> > source: "#{action('myBean', 'myAction', params...)}"
>> >>> >>>> > });
>> >>> >>>> >
>> >>> >>>> > @Named("myBean")
>> >>> >>>> > @RequestScoped
>> >>> >>>> > public class MyBean {
>> >>> >>>> > @Action
>> >>> >>>> > // userId param with automatic converter lookup
>> >>> >>>> > public String myAction(String myUrlParam, User
>> userId) {
>> >>> >>>> > return response;
>> >>> >>>> > }
>> >>> >>>> > }
>> >>> >>>> >
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> Yes, that's one good point. I have seen too. It could be good to
>> have
>> >>> >>>> an EL function that renders the endpoint url automatically. In
>> this
>> >>> >>>> case,
>> >>> >>>> you don't really care how the endpoind url is generated, as long
>> as
>> >>> >>>> when the javascript on the client side invokes the url you get
>> the
>> >>> >>>> pointed method executed.
>> >>> >>>>
>> >>> >>>> You could also want to bind the url to the component itself. The
>> case
>> >>> >>>> is
>> >>> >>>> you are writing a composite component and the component requires
>> >>> >>>> the url, so you annotate a method in the base component class to
>> >>> >>>> deal with this. In the GET case you don't have the view state,
>> so the
>> >>> >>>> component state is not restored, but in the POST case you can
>> >>> >>>> submit the view state (for example calling a defined javascript
>> >>> >>>> function)
>> >>> >>>> and the code will execute an invokeOnComponent call on the
>> server.
>> >>> >>>>
>> >>> >>>> > 4) Allow action rendering in in a normal lifecycle:
>> >>> >>>> >
>> >>> >>>> > <ui:renderAction action="#{myBrean.myAction(bean.value,
>> 1)}" />
>> >>> >>>> >
>> >>> >>>>
>> >>> >>>> Could you please describe better this case? So you execute the
>> >>> >>>> action,
>> >>> >>>> but the lifecycle goes on as usual?
>> >>> >>>>
>> >>> >>>> > 5) Action + facelets rendering -> question 1
>> >>> >>>> > Currently no idea how a integration should look like.
>> >>> >>>> >
>> >>> >>>> >
>> >>> >>>>
>> >>> >>>> I still don't have clear this point, but I can imagine you can
>> return
>> >>> >>>> XML from the server and parse it on the client somehow. Obviously
>> >>> >>>> we need to find out how to do it.
>> >>> >>>>
>> >>> >>>> regards,
>> >>> >>>>
>> >>> >>>> Leonardo Uribe
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> >
>> >>> >>>> >
>> >>> >>>> > 2014-04-22 18:24 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>> >>> >>>> >
>> >>> >>>> >> Hi
>> >>> >>>> >>
>> >>> >>>> >> In few word, the difficulty in this stuff is the context. If
>> you
>> >>> >>>> >> take
>> >>> >>>> >> a
>> >>> >>>> >> look
>> >>> >>>> >> at the example proposed:
>> >>> >>>> >>
>> >>> >>>> >> @Named("myBean")
>> >>> >>>> >> @RequestScoped
>> >>> >>>> >> public class MyBean implements Serializable {
>> >>> >>>> >>
>> >>> >>>> >> @RequestMapping(value = "/form1b.xhtml")
>> >>> >>>> >> public String form1() {
>> >>> >>>> >> String inputText1 = (String)
>> >>> >>>> >> FacesContext.getCurrentInstance().
>> >>> >>>> >>
>> >>> >>>> >>
>> getExternalContext().getRequestParameterMap().get("inputText1");
>> >>> >>>> >> setValue("We set inputText1 manually to - " +
>> inputText1);
>> >>> >>>> >> return "/form1b.xhtml";
>> >>> >>>> >> }
>> >>> >>>> >>
>> >>> >>>> >> }
>> >>> >>>> >>
>> >>> >>>> >> To call the method you need to restore the context first of
>> the
>> >>> >>>> >> parent
>> >>> >>>> >> bean and also there is a call to
>> >>> >>>> >> FacesContext.getCurrentInstance(),
>> >>> >>>> >> so at that point it should be a valid FacesContext instance.
>> >>> >>>> >>
>> >>> >>>> >> In JSF 2.2 the lifecycle has 3 methods:
>> >>> >>>> >>
>> >>> >>>> >> //JSF 2.2: attach window
>> >>> >>>> >> _lifecycle.attachWindow(facesContext);
>> >>> >>>> >> // If this returns false, handle as follows:
>> >>> >>>> >> // call
>> >>> >>>> >> Lifecycle.execute(javax.faces.context.FacesContext)
>> >>> >>>> >> _lifecycle.execute(facesContext);
>> >>> >>>> >> // followed by
>> >>> >>>> >> Lifecycle.render(javax.faces.context.FacesContext).
>> >>> >>>> >> _lifecycle.render(facesContext);
>> >>> >>>> >>
>> >>> >>>> >> The idea is create a LifecycleWrapper that on
>> lifecycle.execute()
>> >>> >>>> >> implements a front controller pattern, doing the necessary
>> steps
>> >>> >>>> >> to
>> >>> >>>> >> get the bean from the underlying CDI container and call the
>> >>> >>>> >> method.
>> >>> >>>> >> If no method is called, continue as usual.
>> >>> >>>> >>
>> >>> >>>> >> The idea is not replicate all the features that an action
>> source
>> >>> >>>> >> framework
>> >>> >>>> >> provides, just the important ones to deal with the cases we
>> have
>> >>> >>>> >> found
>> >>> >>>> >> where this can be useful for JSF, or try to reutilize what's
>> >>> >>>> >> already
>> >>> >>>> >> available in JSF. It will take some time to get it out, but I
>> >>> >>>> >> think
>> >>> >>>> >> if
>> >>> >>>> >> we can solve the use cases proposed, the final result will be
>> >>> >>>> >> something
>> >>> >>>> >> valuable.
>> >>> >>>> >>
>> >>> >>>> >> regards,
>> >>> >>>> >>
>> >>> >>>> >> Leonardo
>> >>> >>>> >>
>> >>> >>>> >> 2014-04-22 16:03 GMT+02:00 Karl Kildén <karl.kilden@gmail.com
>> >:
>> >>> >>>> >> > +1 To the idea
>> >>> >>>> >> >
>> >>> >>>> >> >
>> >>> >>>> >> >
>> >>> >>>> >> >
>> >>> >>>> >> > On 22 April 2014 15:53, Leonardo Uribe <lu...@gmail.com>
>> wrote:
>> >>> >>>> >> >>
>> >>> >>>> >> >> Hi Thomas
>> >>> >>>> >> >>
>> >>> >>>> >> >> Yes, the idea is do something similar. The only thing we
>> need
>> >>> >>>> >> >> to
>> >>> >>>> >> >> find
>> >>> >>>> >> >> out is how to do it in a way that fits better with JSF.
>> >>> >>>> >> >>
>> >>> >>>> >> >> There are different people interested in this:
>> >>> >>>> >> >>
>> >>> >>>> >> >> - Some people wants to use JSF as a template engine,
>> because
>> >>> >>>> >> >> Facelets with JSF 2 Resource Handling and JSF 2.2 Resource
>> >>> >>>> >> >> Library
>> >>> >>>> >> >> Contracts can be an effective solution for server side
>> >>> >>>> >> >> templating.
>> >>> >>>> >> >>
>> >>> >>>> >> >> - Some people want to use a JSF component library but they
>> need
>> >>> >>>> >> >> to
>> >>> >>>> >> >> fill some gaps, like for example create a custom component
>> and
>> >>> >>>> >> >> on
>> >>> >>>> >> >> the way they need to create a JSON endpoint. An mixed
>> JSF-MVC
>> >>> >>>> >> >> approach can be an effective solution.
>> >>> >>>> >> >>
>> >>> >>>> >> >> I think the mentioned example is just half of the solution.
>> >>> >>>> >> >> That's
>> >>> >>>> >> >> the reason why I'm gathering the use cases where this can
>> be
>> >>> >>>> >> >> useful. The plan is write a prototype and discuss it, to
>> see
>> >>> >>>> >> >> how
>> >>> >>>> >> >> far
>> >>> >>>> >> >> can we go with this.
>> >>> >>>> >> >>
>> >>> >>>> >> >> regards,
>> >>> >>>> >> >>
>> >>> >>>> >> >> Leonardo
>> >>> >>>> >> >>
>> >>> >>>> >> >> 2014-04-22 15:21 GMT+02:00 Thomas Andraschko
>> >>> >>>> >> >> <an...@gmail.com>:
>> >>> >>>> >> >> > Hi Leo,
>> >>> >>>> >> >> >
>> >>> >>>> >> >> > +1 for the idea.
>> >>> >>>> >> >> > Would it be similiar to:
>> >>> >>>> >> >> >
>> >>> >>>> >> >> >
>> >>> >>>> >> >> >
>> >>> >>>> >> >> >
>> >>> >>>> >> >> >
>> >>> >>>> >> >> >
>> https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra
>> >>> >>>> >> >> > ?
>> >>> >>>> >> >> >
>> >>> >>>> >> >> > Regards,
>> >>> >>>> >> >> > Thomas
>> >>> >>>> >> >> >
>> >>> >>>> >> >> >
>> >>> >>>> >> >> > 2014-04-22 15:13 GMT+02:00 Leonardo Uribe <
>> lu4242@gmail.com>:
>> >>> >>>> >> >> >
>> >>> >>>> >> >> >> Hi
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> Over the time, with the new javascript libraries out
>> there
>> >>> >>>> >> >> >> that
>> >>> >>>> >> >> >> makes
>> >>> >>>> >> >> >> easier to make reliable code on the client side, there
>> are
>> >>> >>>> >> >> >> more
>> >>> >>>> >> >> >> and
>> >>> >>>> >> >> >> more people interested in an approach that can take
>> >>> >>>> >> >> >> advantage
>> >>> >>>> >> >> >> of
>> >>> >>>> >> >> >> the good parts that JSF 2.2 already has, but without get
>> >>> >>>> >> >> >> into
>> >>> >>>> >> >> >> the
>> >>> >>>> >> >> >> JSF
>> >>> >>>> >> >> >> lifecycle complexities. It could be good if we provide
>> a new
>> >>> >>>> >> >> >> module
>> >>> >>>> >> >> >> inside MyFaces Commons that allow to do things like in
>> >>> >>>> >> >> >> Spring
>> >>> >>>> >> >> >> MVC
>> >>> >>>> >> >> >> or
>> >>> >>>> >> >> >> JAX-RS but also integrated with JSF.
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> For example:
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> - Create a JSON response from a managed bean and bind
>> it to
>> >>> >>>> >> >> >> a
>> >>> >>>> >> >> >> component
>> >>> >>>> >> >> >> using javascript.
>> >>> >>>> >> >> >> - Define REST endpoints into CDI beans.
>> >>> >>>> >> >> >> - Provide javascript functions that can invoke a JSF
>> POST or
>> >>> >>>> >> >> >> a
>> >>> >>>> >> >> >> GET.
>> >>> >>>> >> >> >> ...
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> I have sended already an email to the EG list related to
>> >>> >>>> >> >> >> this
>> >>> >>>> >> >> >> stuff,
>> >>> >>>> >> >> >> indicating some use cases where this can be useful. See:
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >>
>> https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-04/message/5
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> CASE 1: Autocomplete component
>> >>> >>>> >> >> >> CASE 2: Captcha component
>> >>> >>>> >> >> >> CASE 3: Excel/PDF/Text/CSV export
>> >>> >>>> >> >> >> CASE 4: REST
>> >>> >>>> >> >> >> CASE 5: Websockets
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> The idea is create two things:
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> - An extension from the JSF lifecycle.
>> >>> >>>> >> >> >> - A javascript library that can be called from the
>> client
>> >>> >>>> >> >> >> side
>> >>> >>>> >> >> >> to
>> >>> >>>> >> >> >> invoke
>> >>> >>>> >> >> >> JSF on the server.
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> The final result will look similar to an action source
>> >>> >>>> >> >> >> framework,
>> >>> >>>> >> >> >> some annotations that can be parsed to define a
>> controller
>> >>> >>>> >> >> >> algorithm,
>> >>> >>>> >> >> >> use JSF as template framework and CDI as the model.
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> In these moments I'm trying to imagine what can we do in
>> >>> >>>> >> >> >> this
>> >>> >>>> >> >> >> case,
>> >>> >>>> >> >> >> so
>> >>> >>>> >> >> >> any suggestion or comment about what people feel
>> missing and
>> >>> >>>> >> >> >> in
>> >>> >>>> >> >> >> that
>> >>> >>>> >> >> >> sense needs to be done is most welcome.
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> regards,
>> >>> >>>> >> >> >>
>> >>> >>>> >> >> >> Leonardo Uribe
>> >>> >>>> >> >> >
>> >>> >>>> >> >> >
>> >>> >>>> >> >
>> >>> >>>> >> >
>> >>> >>>> >
>> >>> >>>> >
>> >>> >>>
>> >>> >>>
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>
>> >>
>>
>>
>
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Posted by Thomas Andraschko <an...@gmail.com>.
Hi Leo,
AFAIR now, your solutions seems to be just a replacement for f:viewAction +
allow different handlers via URL parameters.
Its sound really lightweight and easy actually :)
Does it cover all our requirements from the earlier mails?
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")
})
Regards,
Thomas
2014-05-02 18:47 GMT+02:00 Dora Rajappan <do...@yahoo.com>:
> Hi,
>
> According to Thomas mojarra has a prototype mapping FasesServlet as
> action servlet with lifecycle id as param .
> So this implementation will be part spec and will go to myfaces project!
>
> I think the f:viewParam and f:viewAction is not used very much. It gets
> executed when the page is loaded.
>
> Regarding Bean having RequestMapping and returning a view is same with
> faces-config mapping. And if its partial its like ajax. Good thing is the
> flexibility is added to the Bean.
>
> Its different when its executing a lifecycle phase which is good to
> support and new and may go to myfaces commons project.
>
> Regards,
> Dora Rajappan.
>
> On Wednesday, April 30, 2014 8:58 PM, Leonardo Uribe <lu...@gmail.com>
> wrote:
> Hi
>
> After doing some attempts I found that a syntax like the one in
> spring mvc @RequestMapping fits better:
>
> @ViewAction(value="/sayhello.xhtml", params="action=exportExcel")
> public void method3()
> {
>
> Then in the page you can write something like this:
>
> <h:link outcome="sayhello" value="Export to excel" target="_blank">
> <f:param name="action" value="exportExcel"/>
> </h:link>
>
> This is nice because the url includes the client window id
> automatically in the action.
>
> @RequestMapping propose these fields for matching:
>
> String[] headers
> RequestMethod[] method
> String[] params
> String[] consumes
> String[] produces
>
> But from JSF perspective, the only interesting to add is params. To
> restrict
> the action in case of a POST, we could add a custom param like
>
> boolean processOnPostback
>
> or something like that.
>
> Theoretically, f:viewAction has "rendered" property to restrict the case
> when the action is executed or not, but it is easier to understand the
> annotation syntax to restrict the cases where the action should be
> executed.
>
> In this way, we are adding what is useful and discarding the remaining
> stuff that is just noise for JSF. If anyone feels add something extra can
> be useful, this is a good moment to say it.
>
> regards,
>
> Leonardo Uribe
>
>
> 2014-04-30 14:14 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
> > Hi Thomas
> >
> > TA> cool!
> > TA>
> > TA> Your ViewAction currently returns a string. Is it just a "html"
> string?
> > TA>
> >
> > Since @ViewAction resembles f:viewAction the string is the outcome that
> is used
> > to navigate on invoke application phase. It triggers a navigation. But
> we can
> > do something else, in the wrapper of the method.
> >
> > TA> What about rendering a view/rewrite url like ->
> > TA> @ViewAction("/actions/registragion/start")
> > TA> public void View myAction(
> > TA>
> > TA> return new View("/views/registration/startRegistration.xhtml");
> > TA> }
> > TA>
> >
> > I think it is another different case, that probably will require
> > another annotation. It is something confusing at first view, but
> > I'll try to clarify it here.
> >
> > In an action oriented framework, the path is used to indicate
> > the specific action. For example, /actions/registragion/start is a
> > defined point, so as soon as the user activates it, usually
> > clicking on the related link, something happens in the action
> > and then the control pass to the view.
> >
> > But in a framework like JSF, the control moves from page to
> > page. In other words, it is page centric. So, instead to move
> > into a some intermediate state, the control should go directly to
> > the page and after that, all actions done by components will be
> > handled by the page itself. For example, a form submit is always
> > send as an "action" of the page with these parameters:
> >
> > javax.faces.ViewState
> > [form_clientId]_SUBMIT
> > ....
> >
> > Then, decode() method of the form check which form was
> > submitted and process the necessary operations.
> >
> > Now, let's see what happen with an action oriented framework,
> > for example Spring MVC in a login form (taken from the
> > performance comparison, removing the unnecessary parts):
> >
> > @Controller
> > @Scope("request")
> > @RequestMapping(value = "/home")
> > public class LoginController
> > {
> >
> > @RequestMapping(method = RequestMethod.GET)
> > public String home(Map model)
> > {
> > model.put("loginForm", new LoginForm());
> > return "home";
> > }
> > /*.. more code goes here..*/
> >
> > This is what is on the jsp:
> >
> > <form:form method="post" action="home.do" commandName="loginForm">
> >
> > The model here is different. The control belongs to LoginController,
> > the page has not an associated "implicit" controller, and in the page
> > you must write some lines to give back the control to the controller.
> >
> >
> > Do things like that is a complete nonsense for JSF, because that's
> > the kind of code that cause maintenance problems.
> >
> > There are two options:
> >
> > 1. Put a front controller that sends the control to the bean and then
> > in the bean you can decide which page takes the control. From that
> > point the control does not get back to the bean, and the inner
> > controller (jsf lifecycle) takes care of form submission and the
> > remaining code. A new annotation is required.
> >
> > or
> >
> > 2. Define an special query parameter with the action, so the action is
> > activated based on the value provided in that field.
> >
> > For example:
> >
> > @ViewAction("/section1/*", actionEvent="getList")
> > public void method2()
> > {
> > FacesContext facesContext = FacesContext.getCurrentInstance();
> > /* .... generate custom response ... */
> > facesContext.responseComplete()
> > }
> >
> > or something more simplified
> >
> > @ViewAction("/section1/*", actionEvent="getList")
> > public Content method2()
> > {
> > return new Content("a, b, c");
> > }
> >
> > and do the necessary stuff on the background.
> >
> > I feel inclined to use option 2, because the front controller approach
> > clash with some basic concepts of JSF.
> >
> > TA> Will it also cover Excel/PDF... export?
> >
> > Yes, I think so, but we need to try. Really with the discussion we
> > are trying to understand what's going on and how to adapt it into
> > JSF.
> >
> > If you take a look, the discussion is leading us to something
> > "in the middle". Does it work? does it solve the problem found in JSF?
> > That's something we need to find out.
> >
> > regards,
> >
> > Leonardo Uribe
> >
> >>
> >> Regards,
> >> Thomas
> >>
> >>
> >>
> >> 2014-04-29 20:02 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
> >>
> >>> Hi
> >>>
> >>> I have done a fast prototype, just to check how things could work and
> how
> >>> the
> >>> pieces can be grouped together, and there are some interesting ideas
> that
> >>> are
> >>> worth to consider.
> >>>
> >>> In JSF 2, when f:viewParam was added, some logic was added to create
> the
> >>> view
> >>> in two steps: first you create the view metadata, where f:viewParam and
> >>> now
> >>> f:viewAction lives and then you "fill" the view, executing facelets
> >>> algorithm
> >>> again and in that way create the full component hierarchy.
> >>>
> >>> One idea it came to my mind is create a ViewDeclarationLanguage wrapper
> >>> and
> >>> override getViewMetadata(...) method to inject a f:viewAction component
> >>> according to the definition in the CDI bean. For example:
> >>>
> >>> @Named("sayHelloBean")
> >>> @ActionController
> >>> @RequestScoped
> >>> public class SayHelloBean
> >>> {
> >>>
> >>> @ViewAction("/section1/*")
> >>> public String method2()
> >>> {
> >>>
> >>> That makes all views that match with the pattern provided to have an
> extra
> >>> f:viewAction component, with the existing rules that apply for them.
> You
> >>> can
> >>> also imagine something like this:
> >>>
> >>> @ViewAction("/section1/*")
> >>> public String method2(@ViewParam String param1)
> >>>
> >>> What we are saying with the syntax is: "... all views that are are
> part of
> >>> section1 will have a ViewAction listener and will have a view param
> called
> >>> param1. ...".
> >>>
> >>> This approach the following advantages:
> >>>
> >>> - Provide a way to define view actions without override the html
> markup in
> >>> every top level template page.
> >>> - It reuse the existing logic for JSF view action, so it is easy to
> >>> understand
> >>> for the users.
> >>> - It can be included in JSF 2.2.
> >>> - JSF is still in control of the navigation at all times, because
> there is
> >>> no
> >>> Front Controller.
> >>> - The context will be automatically managed by JSF.
> >>>
> >>> but also has the following limitations:
> >>>
> >>> - With an action source framework it is possible to define a wide
> range of
> >>> conditions to activate the action. For example if the request is a GET
> or
> >>> a
> >>> POST, of if it sends some specific header, even take parameters from
> the
> >>> path.
> >>> In this solution, the viewId is used for pattern maching and only
> >>> considers
> >>> query parameters.
> >>> - It bounds the action to a view, so if there is no view, there is no
> >>> action.
> >>>
> >>>
> >>> And we finally get to the central point of discussion: How much
> >>> flexibility we
> >>> really need or the users want to define view actions?
> >>>
> >>> Remember the first lines in JSF spec:
> >>>
> >>> "... JSF’s core architecture is designed to be independent of specific
> >>> protocols and markup. ..."
> >>>
> >>> Now take a look for example about what JAX-RS spec says about:
> >>>
> >>> "... The following are the goals of the API: POJO-based, HTTP-centric,
> >>> Format independence, Container independence, Inclusion in Java EE ..."
> >>>
> >>> In that sense, all other features provided by action source frameworks
> are
> >>> just useless for JSF, besides include a way to declare view actions
> into
> >>> CDI beans.
> >>>
> >>> If we review the related requeriments Thomas Andraschko provided:
> >>>
> >>> 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
> >>>
> >>> I think with the approach proposed we can comply with the requirements.
> >>>
> >>> Maybe we should forget about the rest, and focus our efforts in explore
> >>> this approach.
> >>>
> >>> DR>> +1 for the idea. Are you going to have two sets of release jars
> with
> >>> DR>> and without extensions ? Is it going to be a different project?
> >>>
> >>> It is still a proposal (please read the subject of the message), so it
> >>> is too early to say something about.
> >>>
> >>> DR>> Spring MVC beans can be configured to be accessed from the
> >>> ManagedBeans.
> >>> DR>> You are talking about the spring beans integration in the jsf
> >>> elements?
> >>>
> >>> The mail is clear in this. The idea is explore how to do things like
> with
> >>> an action source framework, but in JSF 2.2 / CDI, probably writing a
> CDI
> >>> extension. There is no integration code with a third party framework,
> the
> >>> idea is found new ways to solve existing problems.
> >>>
> >>> regards,
> >>>
> >>> Leonardo Uribe
> >>>
> >>> 2014-04-29 18:32 GMT+02:00 Dora Rajappan <do...@yahoo.com>:
> >>> > +1 for the idea. Are you going to have two sets of release jars with
> >>> > and
> >>> > without extensions ? Is it going to be a different project?
> >>> >
> >>> > Spring MVC beans can be configured to be accessed from the
> ManagedBeans.
> >>> > You
> >>> > are talking about the spring beans integration in the jsf elements?
> >>> >
> >>> > Regards,
> >>> > Dora Rajappan.
> >>> > On Friday, April 25, 2014 7:03 PM, Thomas Andraschko
> >>> > <an...@gmail.com> wrote:
> >>> > Hi,
> >>> >
> >>> > sounds good enough for a first prototype -> +1
> >>> >
> >>> > Regards,
> >>> > Thomas
> >>> >
> >>> >
> >>> > 2014-04-25 15:23 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
> >>> >
> >>> > Hi
> >>> >
> >>> > There are different things we would like to include in this module.
> For
> >>> > now, let's focus on rethink how "actions" should be processed in JSF.
> >>> >
> >>> > To make things easier, let's start with a comparison between
> >>> > f:viewAction
> >>> > and
> >>> > a solution that involves a front controller and some actions defines
> >>> > using
> >>> > annotations in a CDI bean.
> >>> >
> >>> > In the first case, the developer defines the action in the page
> using a
> >>> > tag:
> >>> >
> >>> > SOLUTION 1:
> >>> >
> >>> > <f:metadata>
> >>> > <f:viewParam name="id" value="#{personPage.id}"/>
> >>> > <f:viewAction action="#{personPage.loadPerson}"/>
> >>> > </f:metadata>
> >>> >
> >>> > The alternative approach to discuss here is use a managed bean that
> >>> > defines
> >>> > a path that will work as an starting point:
> >>> >
> >>> > SOLUTION 2:
> >>> >
> >>> > @Named("myBean")
> >>> > @ActionController
> >>> > @RequestScoped
> >>> > public class MyBean
> >>> > {
> >>> > @Action("/actions/do/something")
> >>> > // userId param with automatic converter lookup
> >>> > public View myAction()
> >>> > {
> >>> > return new
> View("/views/registration/startRegistration.xhtml");
> >>> > }
> >>> > }
> >>> >
> >>> > There are multiple differences between both solutions:
> >>> >
> >>> > * <f:viewAction> requires a view to be defined, so when the
> >>> > f:viewAction is
> >>> > processed, there is a FacesContext, a client window set (if any)
> and
> >>> > there
> >>> > is a view context too. With the annotations there is no associated
> >>> > view,
> >>> > so it can't be a valid UIViewRoot at that moment.
> >>> >
> >>> > * The annotation approach allows navigation without being in a view.
> >>> > With
> >>> > f:viewAction it is possible to cause a navigation like with a
> >>> > h:commandButton.
> >>> >
> >>> > * f:viewAction still requires a managed bean to handle the action.
> The
> >>> > syntax
> >>> > using annotations is more compact, because requires only the
> managed
> >>> > bean.
> >>> >
> >>> > * f:viewAction is activated every time the page is loaded by first
> time
> >>> > (in practice, every time a GET is processed), but with the
> >>> > annotations
> >>> > it is necessay to define the conditions under the action is
> >>> > activated.
> >>> >
> >>> > I think f:viewAction and the annotation approach are different
> things,
> >>> > even
> >>> > if they share some similarities.
> >>> >
> >>> > JSF has been always a "page centric" framework. The developer write
> some
> >>> > pages, but to define the navigation, the developer has the option of
> >>> > write
> >>> > some navigation rules or he/she can also use an implicit navigation.
> >>> >
> >>> > f:viewAction design fits really well with JSF, as long as you are
> >>> > dealing
> >>> > with
> >>> > "view actions". But in some cases, the action doesn't have any
> >>> > relationship
> >>> > with any view. That's the case where an action defined into a managed
> >>> > bean
> >>> > has
> >>> > sense.
> >>> >
> >>> > For example, when the user want to verify a condition for all pages
> >>> > inside
> >>> > a folder. If the condition is not valid, an specified page should be
> >>> > rendered.
> >>> > Some solutions for that problem are:
> >>> >
> >>> > 1. Create a filter and handle the logic there
> >>> > 2. Create a ViewHandler wrapper, override createView(...) and handle
> the
> >>> > logic
> >>> > there.
> >>> >
> >>> > But it would be nice to have something like this:
> >>> >
> >>> > @Named("myBean")
> >>> > @ActionController
> >>> > @RequestScoped
> >>> > public class CheckUserBean
> >>> > {
> >>> > @Priority(Priorities.USER)
> >>> > @Action("/registration/*")
> >>> > // userId param with automatic converter lookup
> >>> > public View myAction()
> >>> > {
> >>> > if (the current flow is not active)
> >>> > {
> >>> > return new Navigation("registration");
> >>> > }
> >>> > // Otherwise continue to the expected page
> >>> > return null;
> >>> > }
> >>> > }
> >>> >
> >>> > In this case we have an action that is executed based on a pattern,
> in a
> >>> > specified moment, for a set of pages, and that could cause a
> navigation
> >>> > to another page or could not affect the navigation and JSF lifecycle
> >>> > takes
> >>> > place as usual.
> >>> >
> >>> > The other kind of action proposed:
> >>> >
> >>> > @Action("/actions/do/something")
> >>> > // userId param with automatic converter lookup
> >>> > public View myAction()
> >>> > {
> >>> > return new
> View("/views/registration/startRegistration.xhtml");
> >>> > }
> >>> >
> >>> > It can be something like this too:
> >>> >
> >>> > @Action("/actions/do/something")
> >>> > // userId param with automatic converter lookup
> >>> > public void myAction()
> >>> > {
> >>> > FacesContext facesContext = FacesContext.getCurrentInstance();
> >>> >
> >>> > /* ... generate text, pdf, xml or whatever ...*/
> >>> >
> >>> > facesContext.responseComplete();
> >>> > }
> >>> >
> >>> > the responseComplete() cause the lifecycle to be skipped.
> >>> >
> >>> > I think these ideas does not overlap or replace the utility of
> >>> > f:viewAction,
> >>> > and instead the aim is solve a different problem. I'll try to make a
> >>> > prototype with the ideas exposed here. I have some more ideas for the
> >>> > other
> >>> > requeriments we have, but for now the idea is focus on what looks
> more
> >>> > important or useful.
> >>> >
> >>> > Suggestions are welcome.
> >>> >
> >>> > regards,
> >>> >
> >>> > Leonardo
> >>> >
> >>> > 2014-04-23 15:45 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
> >>> >> Hi
> >>> >>
> >>> >> 2014-04-23 14:16 GMT+02:00 Thomas Andraschko
> >>> >> <an...@gmail.com>:
> >>> >>> LU>> 4) Allow action rendering in in a normal lifecycle:
> >>> >>> LU>>
> >>> >>> LU>> <ui:renderAction action="#{myBrean.myAction(
> >>> >>> LU>bean.value, 1)}" />
> >>> >>> LU>>
> >>> >>> LU>
> >>> >>> LU>Could you please describe better this case? So you execute the
> >>> >>> action,
> >>> >>> LU> but the lifecycle goes on as usual?
> >>> >>
> >>> >>
> >>> >> TA> It's just a component, which renders the returned html string
> from
> >>> >> the
> >>> >> TA> action into the ResponseWriter.
> >>> >> TA> Something like a include for the action return value.
> >>> >> TA>
> >>> >> TA>
> >>> >> TA> This would be also helpful if we combine facelet rendering +
> >>> >> actions.
> >>> >> TA> In ASP.NET MVC, the action could also return a
> View/PartialView:
> >>> >> TA>
> >>> >> TA>
> >>> >> TA>> @Named("myBean")
> >>> >> TA>> @RequestScoped
> >>> >> TA>> public class MyBean {
> >>> >> TA>> @Action
> >>> >> TA>> // userId param with automatic converter lookup
> >>> >> TA>> public PartialView myAction(String myUrlParam, User
> >>> >> userId)
> >>> >> {
> >>> >> TA>> return new
> >>> >> TA>> PartialView("/META-INF/mylib/myincludes/myfile.xhtml");
> >>> >> TA>> }
> >>> >> TA>> }
> >>> >> TA>
> >>> >> TA> It would load the xhtml, renders the xhtml and return the
> rendered
> >>> >> html
> >>> >> TA> string - called via ui:renderAction or via URL.
> >>> >> TA>
> >>> >>
> >>> >> So you mean use JSF as a template engine to render some html
> fragments.
> >>> >> I think it can be done.
> >>> >>
> >>> >> This feature is something controversial, because it could be used
> >>> >> wrongly.
> >>> >> For example, you have a page fragment and you want to update it
> using
> >>> >> this stuff and some javascript. Since you are bypassing JSF, the
> >>> >> results
> >>> >> can be unexpected, because JSF is no longer in control of the view
> >>> >> state
> >>> >> anymore. The right way is affect the component state (or the model
> >>> >> state),
> >>> >> so when it is rendered it gets updated. The best way to do it, is
> with
> >>> >> ajax,
> >>> >> because ajax knows about the relationship between different
> components.
> >>> >>
> >>> >> Also, you could have situations when the ids are not correctly
> >>> >> generated,
> >>> >> and at the end have duplicate ids. Again, the solution is add or
> remove
> >>> >> the
> >>> >> component from the component tree programmatically, so JSF can have
> >>> >> the change to deal with this problem properly.
> >>> >>
> >>> >> More than a PartialView, I think in this case JSF is used as a raw
> html
> >>> >> or
> >>> >> xml generator. For example, the html in this case could be a
> formatted
> >>> >> message and so on.
> >>> >>
> >>> >> I think it is better if we avoid the term "PartialView" and instead
> we
> >>> >> provide
> >>> >> something more abstract like "Response" or "MarkupFragment" or
> >>> >> something like that. Something that indicates that this is not part
> of
> >>> >> the
> >>> >> view itself, and instead is part of the "client state".
> >>> >>
> >>> >>>
> >>> >>>
> >>> >>> I think we could also completely rebuild the GET functionality for
> >>> >>> actions.
> >>> >>> Maybe could just render the startRegistration.xhtml via a normal
> JSF
> >>> >>> lifecycle after the action call.
> >>> >>>
> >>> >>>> @Named("myBean")
> >>> >>>> @RequestScoped
> >>> >>>> public class MyBean {
> >>> >>>> @Action(mapping = "/actions/do/something")
> >>> >>>
> >>> >>>> // userId param with automatic converter lookup
> >>> >>>> public View myAction() {
> >>> >>>> return new
> >>> >>>> View("/views/registration/startRegistration.xhtml");
> >>> >>>> }
> >>> >>>> }
> >>> >>>
> >>> >>
> >>> >> It can be done. In fact, it works like a url rewriting. Maybe it is
> >>> >> more
> >>> >> straighforward for users after all, because with f:viewAction, you
> >>> >> can't
> >>> >> control the page, but with this, you can add some logic before the
> >>> >> final page is processed, like for example a conditional and so on.
> >>> >>
> >>> >>> Just some ideas for a more complete add-on.
> >>> >>> That would cover the "view" and "controller". The "model" are
> actually
> >>> >>> the
> >>> >>> beans via EL.
> >>> >>>
> >>> >>> Don't know if it really fits JSF or if there are better concepts -
> but
> >>> >>> that
> >>> >>> are almost all core features of ASP.NET MVC.
> >>> >>>
> >>> >>>
> >>> >>
> >>> >> I think what we are doing here instead is take the best we found
> from
> >>> >> the
> >>> >> things we know that works. The challenge is integrate in a coherent
> >>> >> way.
> >>> >>
> >>> >> For example, JSF as a component oriented framework has the concept
> >>> >> of clientIds associated with components. This is very helpful when
> you
> >>> >> move code from one place to another, because the generated ids on
> >>> >> the client side are updated properly. In an action oriented
> framework,
> >>> >> that's
> >>> >> a complete mess. The idea is preserve the JSF abstraction, that
> means
> >>> >> components that can be assembled in a hierarchical way, and that
> also
> >>> >> means this tree has a similar structure on the client.
> >>> >>
> >>> >> We can find workarounds. For example, bind the html generation to
> >>> >> a component, so we say "... generate an html fragment, but keep in
> mind
> >>> >> that chunk will be used in this component or a component with this
> >>> >> client id ..." So, the fragment is encapsulated in a jsf component
> that
> >>> >> implements NamingContainer and generates the specified clientId.
> >>> >> That could work. But I suppose it should be MyFaces Core
> implementation
> >>> >> specific, because we need to indicate to facelets the way how the
> ids
> >>> >> should be generated.
> >>> >>
> >>> >> regards,
> >>> >>
> >>> >> Leonardo Uribe
> >>> >>
> >>> >>>
> >>> >>> 2014-04-23 13:40 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
> >>> >>>
> >>> >>>> Hi
> >>> >>>>
> >>> >>>> 2014-04-23 11:54 GMT+02:00 Thomas Andraschko
> >>> >>>> <an...@gmail.com>:
> >>> >>>> TA> Hi,
> >>> >>>> TA>
> >>> >>>> TA> the most important question for me is actually:
> >>> >>>> TA>
> >>> >>>> TA> 1) How much should we really mix actions with facelets
> rendering?
> >>> >>>> TA>
> >>> >>>> TA> There are soooo many things to consider. As you already said
> in
> >>> >>>> your
> >>> >>>> specs
> >>> >>>> TA> post: viewstate, windowid, viewscoped, ....
> >>> >>>> TA>
> >>> >>>>
> >>> >>>> I think the best way to deal with facelets rendering is use the
> >>> >>>> standard
> >>> >>>> ajax.
> >>> >>>> I know in an action source framework people have to do the ajax
> stuff
> >>> >>>> "by hand", which means use the template framework to calculate a
> >>> >>>> fragment
> >>> >>>> of the response. That's a step back.
> >>> >>>>
> >>> >>>> Instead, this is for the case when you have a page in the client
> and
> >>> >>>> you
> >>> >>>> need
> >>> >>>> to communicate with the server to get some information, but the
> page
> >>> >>>> structure
> >>> >>>> does not change. For example, an autocomplete component or a
> >>> >>>> datatable
> >>> >>>> component. In that case, you only need the data usually in json
> >>> >>>> format,
> >>> >>>> and
> >>> >>>> there is a javascript already in place to deal with that data and
> >>> >>>> change
> >>> >>>> the
> >>> >>>> state of the client.
> >>> >>>>
> >>> >>>> The point is deal with the context in general. So if you send a
> POST
> >>> >>>> from
> >>> >>>> the
> >>> >>>> client, and you provide the windowid and the viewstate token, it
> >>> >>>> should
> >>> >>>> be
> >>> >>>> processed, and the response should update the viewstate if
> necessary.
> >>> >>>> That's why we need some javascript on the client to wire things
> up.
> >>> >>>>
> >>> >>>> It could be possible a complex case, where we need a json response
> >>> >>>> but
> >>> >>>> the response triggers an ajax update from the server. It can be
> done,
> >>> >>>> with
> >>> >>>> some javascript code.
> >>> >>>>
> >>> >>>> >
> >>> >>>> > For me the most important things are actually:
> >>> >>>> >
> >>> >>>> > 1) possibility to use a normal JSF lifecycle for the first GET
> >>> >>>> > request
> >>> >>>>
> >>> >>>> I agree with you, because in the first request you are just
> building
> >>> >>>> the
> >>> >>>> view,
> >>> >>>> no special things there.
> >>> >>>>
> >>> >>>> > 2) allow action handling and custom response for POST actions
> >>> >>>>
> >>> >>>> Yes.
> >>> >>>>
> >>> >>>> > 3) normal action handling like in asp.net MVC + a EL util
> function
> >>> >>>> > to
> >>> >>>> > generate the action URL
> >>> >>>> >
> >>> >>>> > $('#input').autocomplete({
> >>> >>>> > source: "#{action('myBean', 'myAction', params...)}"
> >>> >>>> > });
> >>> >>>> >
> >>> >>>> > @Named("myBean")
> >>> >>>> > @RequestScoped
> >>> >>>> > public class MyBean {
> >>> >>>> > @Action
> >>> >>>> > // userId param with automatic converter lookup
> >>> >>>> > public String myAction(String myUrlParam, User userId)
> {
> >>> >>>> > return response;
> >>> >>>> > }
> >>> >>>> > }
> >>> >>>> >
> >>> >>>>
> >>> >>>>
> >>> >>>> Yes, that's one good point. I have seen too. It could be good to
> have
> >>> >>>> an EL function that renders the endpoint url automatically. In
> this
> >>> >>>> case,
> >>> >>>> you don't really care how the endpoind url is generated, as long
> as
> >>> >>>> when the javascript on the client side invokes the url you get the
> >>> >>>> pointed method executed.
> >>> >>>>
> >>> >>>> You could also want to bind the url to the component itself. The
> case
> >>> >>>> is
> >>> >>>> you are writing a composite component and the component requires
> >>> >>>> the url, so you annotate a method in the base component class to
> >>> >>>> deal with this. In the GET case you don't have the view state, so
> the
> >>> >>>> component state is not restored, but in the POST case you can
> >>> >>>> submit the view state (for example calling a defined javascript
> >>> >>>> function)
> >>> >>>> and the code will execute an invokeOnComponent call on the server.
> >>> >>>>
> >>> >>>> > 4) Allow action rendering in in a normal lifecycle:
> >>> >>>> >
> >>> >>>> > <ui:renderAction action="#{myBrean.myAction(bean.value, 1)}"
> />
> >>> >>>> >
> >>> >>>>
> >>> >>>> Could you please describe better this case? So you execute the
> >>> >>>> action,
> >>> >>>> but the lifecycle goes on as usual?
> >>> >>>>
> >>> >>>> > 5) Action + facelets rendering -> question 1
> >>> >>>> > Currently no idea how a integration should look like.
> >>> >>>> >
> >>> >>>> >
> >>> >>>>
> >>> >>>> I still don't have clear this point, but I can imagine you can
> return
> >>> >>>> XML from the server and parse it on the client somehow. Obviously
> >>> >>>> we need to find out how to do it.
> >>> >>>>
> >>> >>>> regards,
> >>> >>>>
> >>> >>>> Leonardo Uribe
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> >
> >>> >>>> >
> >>> >>>> > 2014-04-22 18:24 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
> >>> >>>> >
> >>> >>>> >> Hi
> >>> >>>> >>
> >>> >>>> >> In few word, the difficulty in this stuff is the context. If
> you
> >>> >>>> >> take
> >>> >>>> >> a
> >>> >>>> >> look
> >>> >>>> >> at the example proposed:
> >>> >>>> >>
> >>> >>>> >> @Named("myBean")
> >>> >>>> >> @RequestScoped
> >>> >>>> >> public class MyBean implements Serializable {
> >>> >>>> >>
> >>> >>>> >> @RequestMapping(value = "/form1b.xhtml")
> >>> >>>> >> public String form1() {
> >>> >>>> >> String inputText1 = (String)
> >>> >>>> >> FacesContext.getCurrentInstance().
> >>> >>>> >>
> >>> >>>> >>
> getExternalContext().getRequestParameterMap().get("inputText1");
> >>> >>>> >> setValue("We set inputText1 manually to - " +
> inputText1);
> >>> >>>> >> return "/form1b.xhtml";
> >>> >>>> >> }
> >>> >>>> >>
> >>> >>>> >> }
> >>> >>>> >>
> >>> >>>> >> To call the method you need to restore the context first of the
> >>> >>>> >> parent
> >>> >>>> >> bean and also there is a call to
> >>> >>>> >> FacesContext.getCurrentInstance(),
> >>> >>>> >> so at that point it should be a valid FacesContext instance.
> >>> >>>> >>
> >>> >>>> >> In JSF 2.2 the lifecycle has 3 methods:
> >>> >>>> >>
> >>> >>>> >> //JSF 2.2: attach window
> >>> >>>> >> _lifecycle.attachWindow(facesContext);
> >>> >>>> >> // If this returns false, handle as follows:
> >>> >>>> >> // call
> >>> >>>> >> Lifecycle.execute(javax.faces.context.FacesContext)
> >>> >>>> >> _lifecycle.execute(facesContext);
> >>> >>>> >> // followed by
> >>> >>>> >> Lifecycle.render(javax.faces.context.FacesContext).
> >>> >>>> >> _lifecycle.render(facesContext);
> >>> >>>> >>
> >>> >>>> >> The idea is create a LifecycleWrapper that on
> lifecycle.execute()
> >>> >>>> >> implements a front controller pattern, doing the necessary
> steps
> >>> >>>> >> to
> >>> >>>> >> get the bean from the underlying CDI container and call the
> >>> >>>> >> method.
> >>> >>>> >> If no method is called, continue as usual.
> >>> >>>> >>
> >>> >>>> >> The idea is not replicate all the features that an action
> source
> >>> >>>> >> framework
> >>> >>>> >> provides, just the important ones to deal with the cases we
> have
> >>> >>>> >> found
> >>> >>>> >> where this can be useful for JSF, or try to reutilize what's
> >>> >>>> >> already
> >>> >>>> >> available in JSF. It will take some time to get it out, but I
> >>> >>>> >> think
> >>> >>>> >> if
> >>> >>>> >> we can solve the use cases proposed, the final result will be
> >>> >>>> >> something
> >>> >>>> >> valuable.
> >>> >>>> >>
> >>> >>>> >> regards,
> >>> >>>> >>
> >>> >>>> >> Leonardo
> >>> >>>> >>
> >>> >>>> >> 2014-04-22 16:03 GMT+02:00 Karl Kildén <karl.kilden@gmail.com
> >:
> >>> >>>> >> > +1 To the idea
> >>> >>>> >> >
> >>> >>>> >> >
> >>> >>>> >> >
> >>> >>>> >> >
> >>> >>>> >> > On 22 April 2014 15:53, Leonardo Uribe <lu...@gmail.com>
> wrote:
> >>> >>>> >> >>
> >>> >>>> >> >> Hi Thomas
> >>> >>>> >> >>
> >>> >>>> >> >> Yes, the idea is do something similar. The only thing we
> need
> >>> >>>> >> >> to
> >>> >>>> >> >> find
> >>> >>>> >> >> out is how to do it in a way that fits better with JSF.
> >>> >>>> >> >>
> >>> >>>> >> >> There are different people interested in this:
> >>> >>>> >> >>
> >>> >>>> >> >> - Some people wants to use JSF as a template engine, because
> >>> >>>> >> >> Facelets with JSF 2 Resource Handling and JSF 2.2 Resource
> >>> >>>> >> >> Library
> >>> >>>> >> >> Contracts can be an effective solution for server side
> >>> >>>> >> >> templating.
> >>> >>>> >> >>
> >>> >>>> >> >> - Some people want to use a JSF component library but they
> need
> >>> >>>> >> >> to
> >>> >>>> >> >> fill some gaps, like for example create a custom component
> and
> >>> >>>> >> >> on
> >>> >>>> >> >> the way they need to create a JSON endpoint. An mixed
> JSF-MVC
> >>> >>>> >> >> approach can be an effective solution.
> >>> >>>> >> >>
> >>> >>>> >> >> I think the mentioned example is just half of the solution.
> >>> >>>> >> >> That's
> >>> >>>> >> >> the reason why I'm gathering the use cases where this can be
> >>> >>>> >> >> useful. The plan is write a prototype and discuss it, to see
> >>> >>>> >> >> how
> >>> >>>> >> >> far
> >>> >>>> >> >> can we go with this.
> >>> >>>> >> >>
> >>> >>>> >> >> regards,
> >>> >>>> >> >>
> >>> >>>> >> >> Leonardo
> >>> >>>> >> >>
> >>> >>>> >> >> 2014-04-22 15:21 GMT+02:00 Thomas Andraschko
> >>> >>>> >> >> <an...@gmail.com>:
> >>> >>>> >> >> > Hi Leo,
> >>> >>>> >> >> >
> >>> >>>> >> >> > +1 for the idea.
> >>> >>>> >> >> > Would it be similiar to:
> >>> >>>> >> >> >
> >>> >>>> >> >> >
> >>> >>>> >> >> >
> >>> >>>> >> >> >
> >>> >>>> >> >> >
> >>> >>>> >> >> >
> https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra
> >>> >>>> >> >> > ?
> >>> >>>> >> >> >
> >>> >>>> >> >> > Regards,
> >>> >>>> >> >> > Thomas
> >>> >>>> >> >> >
> >>> >>>> >> >> >
> >>> >>>> >> >> > 2014-04-22 15:13 GMT+02:00 Leonardo Uribe <
> lu4242@gmail.com>:
> >>> >>>> >> >> >
> >>> >>>> >> >> >> Hi
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> Over the time, with the new javascript libraries out
> there
> >>> >>>> >> >> >> that
> >>> >>>> >> >> >> makes
> >>> >>>> >> >> >> easier to make reliable code on the client side, there
> are
> >>> >>>> >> >> >> more
> >>> >>>> >> >> >> and
> >>> >>>> >> >> >> more people interested in an approach that can take
> >>> >>>> >> >> >> advantage
> >>> >>>> >> >> >> of
> >>> >>>> >> >> >> the good parts that JSF 2.2 already has, but without get
> >>> >>>> >> >> >> into
> >>> >>>> >> >> >> the
> >>> >>>> >> >> >> JSF
> >>> >>>> >> >> >> lifecycle complexities. It could be good if we provide a
> new
> >>> >>>> >> >> >> module
> >>> >>>> >> >> >> inside MyFaces Commons that allow to do things like in
> >>> >>>> >> >> >> Spring
> >>> >>>> >> >> >> MVC
> >>> >>>> >> >> >> or
> >>> >>>> >> >> >> JAX-RS but also integrated with JSF.
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> For example:
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> - Create a JSON response from a managed bean and bind it
> to
> >>> >>>> >> >> >> a
> >>> >>>> >> >> >> component
> >>> >>>> >> >> >> using javascript.
> >>> >>>> >> >> >> - Define REST endpoints into CDI beans.
> >>> >>>> >> >> >> - Provide javascript functions that can invoke a JSF
> POST or
> >>> >>>> >> >> >> a
> >>> >>>> >> >> >> GET.
> >>> >>>> >> >> >> ...
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> I have sended already an email to the EG list related to
> >>> >>>> >> >> >> this
> >>> >>>> >> >> >> stuff,
> >>> >>>> >> >> >> indicating some use cases where this can be useful. See:
> >>> >>>> >> >> >>
> >>> >>>> >> >> >>
> >>> >>>> >> >> >>
> >>> >>>> >> >> >>
> >>> >>>> >> >> >>
> >>> >>>> >> >> >>
> >>> >>>> >> >> >>
> >>> >>>> >> >> >>
> https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-04/message/5
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> CASE 1: Autocomplete component
> >>> >>>> >> >> >> CASE 2: Captcha component
> >>> >>>> >> >> >> CASE 3: Excel/PDF/Text/CSV export
> >>> >>>> >> >> >> CASE 4: REST
> >>> >>>> >> >> >> CASE 5: Websockets
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> The idea is create two things:
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> - An extension from the JSF lifecycle.
> >>> >>>> >> >> >> - A javascript library that can be called from the client
> >>> >>>> >> >> >> side
> >>> >>>> >> >> >> to
> >>> >>>> >> >> >> invoke
> >>> >>>> >> >> >> JSF on the server.
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> The final result will look similar to an action source
> >>> >>>> >> >> >> framework,
> >>> >>>> >> >> >> some annotations that can be parsed to define a
> controller
> >>> >>>> >> >> >> algorithm,
> >>> >>>> >> >> >> use JSF as template framework and CDI as the model.
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> In these moments I'm trying to imagine what can we do in
> >>> >>>> >> >> >> this
> >>> >>>> >> >> >> case,
> >>> >>>> >> >> >> so
> >>> >>>> >> >> >> any suggestion or comment about what people feel missing
> and
> >>> >>>> >> >> >> in
> >>> >>>> >> >> >> that
> >>> >>>> >> >> >> sense needs to be done is most welcome.
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> regards,
> >>> >>>> >> >> >>
> >>> >>>> >> >> >> Leonardo Uribe
> >>> >>>> >> >> >
> >>> >>>> >> >> >
> >>> >>>> >> >
> >>> >>>> >> >
> >>> >>>> >
> >>> >>>> >
> >>> >>>
> >>> >>>
> >>> >
> >>> >
> >>> >
> >>> >
> >>
> >>
>
>