Hi
AT> I agree, and that's why there's a flourishing scene of many, many
AT> alternative frameworks. In Java alone I counted well over a hundred of them,
AT> and including non-java solutions there's probably thousands of them.
AT>
AT> But how many full stack frameworks include 2 or more different web
AT> frameworks? Correct me if I'm wrong, but I don't think Spring, Play, Grails
AT> or Ruby on Rails (just to name a few) have two web frameworks.
AT>
Yes, I can see your point, of course, if you compare the level of reusability
you can achieve with JSF against these framework, these ones are too
primitive. But it is worth to mention that all these options in the
code structure
just look the same. The only thing that changes is the syntax. So, in fact
what we have is different variants of the same idea. But the truth is you
cannot make truly reusable component in all these frameworks.
In conclusion, if performance is not an issue, and JSF is a better abstraction,
why do we have to try another thing that aims to do the same but from two
steps back? Well, I have been using "the JSF hat" for years, so it is hard for
me to understand something different, but if the same feeling is here for
other experts, it is clear we should take the other way around, which is extends
JSF so it can process different kinds of actions, just like the prototype I did
before does.
AT> There is one that I know of and that's Microsoft's .Net. But is that really
AT> a good example to follow? Microsoft is somewhat known to have different
AT> alternatives for their own technology (like WinForms vs WPF vs MFC vs bare
AT> Win32 in a way, etc).
AT>
Yes, definitely not a good example to follow, but some ideas could be worth.
AT> There's plenty of choice for Java programmers already. In fact, it's a
AT> complaint one not rarely hears that there's too much too choose from in
AT> Java.
AT>
AT> Java EE simplifies that by being a wildly used full stack framework with
AT> good default choices for everything. If Java EE is going to offer two web
AT> frameworks I'm afraid it will lead to much confusion of what to use.
AT>
I see. In some point you guys need to decide if the route to go is another
"JAX-RS MVC" web framework or improve JSF with these concepts.
AT> Likewise I foresee much doubt in people's minds about whether Oracle will
AT> keep supporting two web frameworks. We have heard the promises and we know
AT> how JSF is the foundation of ADF which is very important to Oracle, but will
AT> people in general also know this?
AT>
In few words, I think people are looking about how JSF will evolve to allow
"smarter clients" written with javascript. In that sense, JSF is perceived as
tightly bound to the server. JSF component libraries already provide
internal solutions to this part, but usually are not meant to be used by users.
The typical use case is the user wants to create a component using some
javascript library, and then he/she found cases where you need something
like get a json or xml response from an endpoint. In that point, JSF doesn't
help much, because it proposes a lifecycle that doesn't help with this case.
It is clear JSF is here to stay. But I think it is a valid concern for
users about
how JSF will deal with the changes, more than if JSF is and will be supported
in the future by Oracle, which is definitely very important.
LU>> From my personal point of view, JAX-RS MVC has sense because there is
LU>> people
LU>> who thinks that this approach has sense. It is a bad pattern? old
LU>> fashioned?
LU>> Who knows, don't care, but it is something accepted, with an audience and
LU>> it
LU>> has sense to give these guys a standard solution. It is worth to do it?
LU>> Maybe,
LU>> maybe not, but if not why some people still use Spring MVC? could it be
LU>> that
LU>> this approach is easier to understand, and only that is its own strength?.
AT> Might be the case, but I'd be wary about any silver bullets. Too often
AT> things that initially look simpler for some use cases appear to have issues
AT> at other places that only become clear when you really use that other thing.
AT> If anything, it would be nice to see some clear examples demonstrating that
AT> Spring MVC is simpler and that this simplicity can only be reached by
AT> following the Spring model as closely as possible.
AT> The point is that I haven't seen much if any such examples. I'm not saying
AT> there aren't any, but just that nobody has provided them in this discussion.
AT> For such a major and perhaps controversial operation I'm really wondering
AT> why the discussion wasn't started with this.
AT>
I think the example to think about is how generate some json or xml or text
response. With Spring MVC or any other similar alternative, you can just write
a method in a controller class and that's it. In the declared method you have
also some parameter-variable mapping and then you can customize the
response, even redirect the response to a template engine that will provide
some logic. I'll take some random example from internet:
@RequestMapping(value="{name}", method = RequestMethod.GET)
public @ResponseBody Shop getShopInJSON(@PathVariable String name) {
Shop shop = new Shop();
shop.setName(name);
shop.setStaffName(new String[]{"xxx1", "xxx2"});
return shop;
}
How to do it with JSF? it can be done, but it will not be pretty.
There is nothing
more simple than write a method to define an endpoint, and that's the kind of
simplicity people want to include in JSF.
The common aspect is execute some logic on the server side that are not
related to the view state itself, but has some effect on the client side.
I have already made some attempts over this, trying to extend f:viewAction
and f:viewParam. For example:
@Named("exporter")
@ActionController
@RequestScoped
public class ExcelExportBean
{
@ViewAction(value="/exporter.xhtml",
params=_at_ViewParam(value="action", expectedValue="exportExcel")
)
public void exportExcel(@ViewParam("id") int id,
@InjectFacesContext FacesContext facesContext) throws IOException
{
With this you define a "virtual" page, that only exists logically, and
the action
is executed if the param "action=exportExcel" matches. Look CDI
injection works too. But the method doesn't have any mention over GET
or POST, because JSF is not bound with any protocol.
The thing is all this one way or another resembles some logic that
JAX-RS already has, or that is more natural for JAX-RS to provide.
Take a look at this:
@ViewAction(value="/testSimpleViewAction.xhtml",
params=_at_ViewParam(value="action", expectedValue="renderMessage")
)
public ActionResponse renderJSFTemplate()
{
return new JSFTemplateResponse("/META-INF/templates/showMessage.xhtml");
}
In this case the idea is use JSF as a template engine, to render some
response that will be consumed by some javascript code in the view.
In other words, the javascript will trigger a GET and then something on
the server receives this request and do some processing not related
to the view.
AT> As you mentioned and researched, the advantage of action frameworks is not
AT> performance, as JSF already outperforms many action oriented frameworks.
AT> With view pooling and further optimisations things could be pushed even
AT> further.
AT>
AT> State is another touted advantage of action frameworks. While not having
AT> much impact on performance, it can sometimes be nasty to deal with. JSF 2.2
AT> already introduced a bare stateless mode and I'm sure we can do even better
AT> for 2.3.
AT>
Please note that view pooling technique relies on state saving
algorithm, otherwise
it will not work. The reason is the view always has "request time"
state, like the
index of the current row in a datatable or some temporal submitted value and
so on, so one way or another you need to cleanup that information to reuse the
view.
Leonardo
> Kind regards,
> Arjan
>
>
>
>
>
>>
>>
>> regards,
>>
>> Leonardo
>>
>>
>> 2014-06-04 13:56 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>> > Hi,
>> >
>> > On Wednesday, June 4, 2014, Edward Burns wrote:
>> >>
>> >>
>> >> AT> but with a small modification to this class and an addition to the
>> >> ID
>> >> AT> generation code for components, it might be quite doable to
>> >> "manually"
>> >> AT> extract the data posted by existing components without needing the
>> >> original
>> >> AT> view.
>> >>
>> >> Arjan, you are describing the single most essential concept of JSF. I
>> >> think it would be a mistake to carry this concept forward into JAX-RS
>> >> MVC.
>> >
>> >
>> > Well, the above was more about thinking (brainstorming) how components
>> > could
>> > possibly be supported (if so required) and less about that they should
>> > be
>> > supported via that mechanism. I'm not even sure yet if such an approach
>> > would work at all.
>> >
>> > It does beg the question of what happens if people do put an h:form or
>> > equivalent on a JAX-RS MVC Facelet. Runtime error? Undefined behavior?
>> > Or
>> > will it just work for those cases where the JAX-RS MVC Controller
>> > happens to
>> > forward to the right view?
>> >
>> >> The action oriented MVC programming model does not have such a
>> >> notion and to introduce it would be making it a different programming
>> >> model.
>> >
>> >
>> > It would, but perhaps this does bring us back to the original question
>> > of
>> > what problem JAX-RS MVC exactly tries to solve. Maybe I've missed it,
>> > but I
>> > haven't seen any clear examples.
>> >
>> > If the problem eventually boils down to the fact that JSF is just not
>> > Spring
>> > MVC (doesn't follow its exact programming model), then of course there's
>> > little else to do then take over that model as accurately as possible.
>> >
>> > I.e. to compare with Java 8 again; if the problem was above all that
>> > Java is
>> > not Haskell, then adding lambdas to Java wouldn't have made much sense
>> > and
>> > the best option would have been to just copy Haskell (or maybe not even
>> > copy
>> > it, just use it as is). But if the problem is more about the fact that
>> > e.g.
>> > making code run in parallel is not that easy in Java 7, then adding
>> > lambdas
>> > to Java 8 is a perfectly acceptable solution.
>> >
>> > Back to JSF, if the problem is that doing pre-processing is too hard, or
>> > that state is still too often required, or that rebuilding the view on a
>> > postback is too costly, etc then there are likely a bunch of possible
>> > solutions, some of which may be inspired by how Spring MVC does things,
>> > but
>> > it wouldn't matter if we'll be making another programming model. Just as
>> > Java and Scala ended up being a different model than Haskell, it
>> > wouldn't
>> > matter if JAX-RS MVC became a different programming model than Spring
>> > MVC if
>> > the goal was never to be exactly like Spring MVC.
>> >
>> > So I think that probably the most interesting thing to add to this
>> > discussion is some concrete use cases that demonstrate why JAX-RS MVC is
>> > exactly necessary.
>> >
>> > Without those it's maybe also hard for JSF users to help out with the
>> > effort. I mean, I personally have some experience with extending JSF in
>> > various ways, and I've got a bunch of ideas how JSF could be modified to
>> > support some action oriented patterns. However, if the idea would be to
>> > mostly copy Spring MVC or to standardize what Jersey has already done,
>> > then
>> > I'm less sure about the ways in which I can contribute.
>> >
>> > Kind regards,
>> > Arjan