On 03/06/14 17:24, Santiago Pericas-Geertsen wrote:
>
> On Jun 3, 2014, at 11:17 AM, Sergey Beryozkin <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>> wrote:
>
>>>
>>> JSF has a number of different parts, not all of which are applicable
>>> to an MVC framework. Some, such as the Facelets templating language,
>>> could be plugged into a JAX-RS based MVC framework --in the same way
>>> JSPs and other templating languages are used today in Jersey for
>>> example. At its core, this is just a convenient mechanism to provide
>>> better text/html representations for resources (Note that I'm not
>>> suggesting that this is the only part of JSF that would be relevant, it
>>> is just an obvious one).
>>
>> So it is JAX-RS based MVC after all, Bill got it right, I misunderstood.
>> Hmm... I thought all we wanted was to make a transparent forward
>> support done and let dealing with the actual templates out of scope to
>> support the case of integrating with the existing view servers.
>>
>> JAX-RS based MVC does seem like a bigger effort indeed
>
> It all depends on how much we decide to do in this first iteration,
> but it is an important part of the work for sure.
>
This is what I'd consider being most important requirement:
- non-intrusiveness into the JAX-RS way of writing services.
This means people can have @Produces with multiple values on the method
optionally returning HTML (ex, HTML, JSON, XML), a method should be just
a regular JAX-RS method returning either Response (possibly empty ->
meaning the liking to a static view/template) or custom bean as opposed
to having to return some specifically introduced type like
'ImplicitView' or similarly named one, I'd rather see an extra method
annotation enabling the submission of a given JAX-RS response into some
template.
- it has to work with the existing view handlers implemented as Servlets
capable of accepting forwards so that people are nor faced with the
choice: either migrate to JAX-RS MVC or just do not bother.
- aligning as much as possible with the existing response processing
flow, 'MVC' handlers should probably be MessageBodyWriter extensions so
that they can feed OutputStream into the template language output
The non-intrusiveness, simplicity and the possibility to integrate with
the existing view servers are key requirements IMHO
> Incidentally, I'd like all of you to take a minute and re-read section
> 2.1 of the last JSR 339:
>
> https://jcp.org/en/jsr/detail?id=339
>
> As I mentioned a few times, this is not something new; we have had the
> intention to explore MVC in JAX-RS for a while. The data that we have
> collected recently has told us that this an area that the EE community
> is still interested in.
No problems on my side as long as we do not invest into managing the
actual view creation process except for delegating to the view handlers,
via some interface or Servlet forward
Cheers, Sergey
>
> -- Santiago
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com