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