[prev in list] [next in list] [prev in thread] [next in thread] 

List:       myfaces-dev
Subject:    Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
From:       Leonardo Uribe <lu4242 () gmail ! com>
Date:       2014-04-30 15:28:20
Message-ID: CABujnVdi4_69yF-oHSoebA=P+E335O89KBk4=4-YwyiDg1_A5A () mail ! gmail ! com
[Download RAW message or body]

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:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > \
> > > > > > > > > > > > ?
> > > > > > > > > > > > 
> > > > > > > > > > > > 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:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > \
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 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
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > 
> > 


[prev in list] [next in list] [prev in thread] [next in thread]