Paul Sandoz wrote:
> I was thinking instead that Jersey could provide some infrastructure
> for managing the set of view templates engines. A template engine
> could provide:
>
> - a message body writer (that specifies the media types produced using
> ConsumeMime)
>
> - the conventions for the template suffixes; and
>
> - the translation of a resource instance and the path that
> was matched to the location of the template file.
>
> Internally Jersey could use an internal "meta" message body writer for
> views or something else when a message body writer is requested, for
> example, Jersey could first search for a message body writer that is
> not for a view, if there is a match use that, otherwise Jersey could
> search for a message body writer for a view and use that. It should
> allow us more flexibility with experimentation of implementation and
> optimization strategies for managing templates.
>
That's similar to what I'm thinking.
> In general this hides complexity for those wishing to plug in their
> own template engine, and we can avoid requiring a change the message
> body writer iface (i.e. it takes time for changes to get agreed and
> propagated to Jersey so it would be good not to be blocked waiting...).
>
> Also i would like to ensure that templates can be used with resources
> whereby a resource is the model. This is the case when there is a
> template but there is no corresponding HTTP method returning a model.
>
> Plus we could have a RenderResponse class that allows a developer to
> explicitly choose a template and pass in a model. I would prefer that
> approach than using annotations to specify such information in this case.
>
>
> Potentially this can be hacked into a branch of Jersey as of now. The
> branch could change the look up of message body writers to not use
> ProviderFactory e.g. in line 249 of
>
> com.sun.ws.rest.spi.container.AbstractContainerResponse
>
> and instead defer to the WebApplication instance for getting an
> appropriate message body writer. The template providers could be
> hacked in by registering via a resource config property.
>
> Would you like to work on a branch of Jersey to experiment?
>
>
I would love to if time permitted. I was hoping to get just enough to
get going on a project I've got coming up soon. Right now I'm
struggling with what direction to go. I really like elements of the
Restlet framework, elements of JSR311 and Jersey, and the Struts REST
plugin. But none of them get me 100% to where I want to be. I'm
getting to a point where I need to make a decision. Hopefully, whatever
decision I make won't be irreversible if it turns out not to work out.
Rich