Hi
AT> So I think that probably the most interesting thing to add to this
AT> discussion is some concrete use cases that demonstrate why JAX-RS MVC is
AT> exactly necessary.
I think it is important here to remember that we have different groups of
users, making applications in different ways, and it is too hard to put all
of them in a single box.
From my personal point of view, JAX-RS MVC has sense because there is people
who thinks that this approach has sense. It is a bad pattern? old fashioned?
Who knows, don't care, but it is something accepted, with an audience and it
has sense to give these guys a standard solution. It is worth to do it? Maybe,
maybe not, but if not why some people still use Spring MVC? could it be that
this approach is easier to understand, and only that is its own strength?.
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