myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Andraschko <andraschko.tho...@gmail.com>
Subject Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Date Sun, 04 May 2014 19:15:29 GMT
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 <dorarajappan@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 <lu4242@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 <lu4242@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 <lu4242@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 <dorarajappan@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
> >>> > <andraschko.thomas@gmail.com> wrote:
> >>> > Hi,
> >>> >
> >>> > sounds good enough for a first prototype -> +1
> >>> >
> >>> > Regards,
> >>> > Thomas
> >>> >
> >>> >
> >>> > 2014-04-25 15:23 GMT+02:00 Leonardo Uribe <lu4242@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 <lu4242@gmail.com>:
> >>> >> Hi
> >>> >>
> >>> >> 2014-04-23 14:16 GMT+02:00 Thomas Andraschko
> >>> >> <andraschko.thomas@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 <lu4242@gmail.com>:
> >>> >>>
> >>> >>>> Hi
> >>> >>>>
> >>> >>>> 2014-04-23 11:54 GMT+02:00 Thomas Andraschko
> >>> >>>> <andraschko.thomas@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 <lu4242@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 <lu4242@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.thomas@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
> >>> >>>> >> >> >
> >>> >>>> >> >> >
> >>> >>>> >> >
> >>> >>>> >> >
> >>> >>>> >
> >>> >>>> >
> >>> >>>
> >>> >>>
> >>> >
> >>> >
> >>> >
> >>> >
> >>
> >>
>
>

Mime
View raw message