Hi,

the most important question for me is actually:

1) How much should we really mix actions with facelets rendering?

There are soooo many things to consider. As you already said in your specs
post: viewstate, windowid, viewscoped, ....


For me the most important things are actually:

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

    $('#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;
         }
     }

4) Allow action rendering in in a normal lifecycle:

   <ui:renderAction action="#{myBrean.myAction(bean.value, 1)}" />

5) Action + facelets rendering -> question 1
    Currently no idea how a integration should look like.




2014-04-22 18:24 GMT+02:00 Leonardo Uribe <lu4...@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.kil...@gmail.com>:
> > +1 To the idea
> >
> >
> >
> >
> > On 22 April 2014 15:53, Leonardo Uribe <lu4...@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
> >> <andraschko.tho...@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 <lu4...@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
> >> >
> >> >
> >
> >
>

Reply via email to