Hi
2014-04-23 11:54 GMT+02:00 Thomas Andraschko <andraschko.tho...@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 <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
>> >> >
>> >> >
>> >
>> >
>
>
