users@jersey.java.net

Re: [Jersey] Trying to include a resource class from jsp

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 15 Dec 2009 12:06:55 +0100

On Dec 15, 2009, at 11:56 AM, Paul Sandoz wrote:

>
> On Dec 15, 2009, at 11:15 AM, Yoryos wrote:
>
>> Hi again!
>>
>> On Tue, Dec 15, 2009 at 11:31, Paul Sandoz <Paul.Sandoz_at_sun.com>
>> wrote:
>>
>> On Dec 14, 2009, at 10:28 PM, Yoryos wrote:
>>
>>> Hi Paul,
>>>
>>> I will try to create a proof of concept tag.
>>>
>>
>> Thanks, i may try and do some investigations as well today since i
>> am proposing this. But, i have to fully admit i do not have much
>> experience writing custom tags!
>>
>>
>> It's been a while since I last had to deal with jsp tags, but they
>> are not rocket science! I'll look at it when I'll find some free
>> time. I'm sure it will not be very hard!
>>
>
> OK. I have just played around with your sample and if i do not
> register your ExtendedJSPTemplateProcessor and modify Jersey's
> RequestDispatcherWrapper such that the include methods is
> implemented as follows:
>
> public void include(ServletRequest req, ServletResponse rsp)
> throws ServletException, IOException {
> ResolvedViewable rv =
> (ResolvedViewable
> )hc
> .getProperties().get("com.sun.jersey.spi.template.ResolvedViewable");
>
> req.setAttribute("httpContext", hc);
> req.setAttribute("resolvingClass", rv.getResolvingClass());
> req.setAttribute("it", it);
> req.setAttribute("_basePath", basePath);
> req.setAttribute("_request", req);
> req.setAttribute("_response", rsp);
> d.include(req,rsp);
> }
>

Clarification: the above does not actually require any modification
because Jersey's JSPTemplateProcessor always calls the forward on the
dispatcher. Thus some tweaks to the ServletContainer.filter method may
be all that is required.

Paul.

> then i include multiple views in the index.jsp, for example:
>
> <h4>Include simpleresource</h4>
> <c:import url="/simpleresource/" />
>
> <h4>Include anotherresource</h4>
> <c:import url="/anotherresource/" />
>
> Then "it" gets resolved correctly for each include.
>
> However, if a view is returned from a resource method that includes
> another view then that include fails, in the sense that nothing is
> included. I think this is because the ExtendedServletContainer needs
> to be tweaked to recognize "re-entrant" inclusion so that the
> ServletContainer.service method is invoked. If that is possible it
> might well be possible to support layered inclusions without a
> custom tag.
>
> Does that make sense?
>
> Would it help if i attach a modified version of your sample?
>
>
>>
>>> Of course I still think that to be able to name the model is a
>>> good idea. Maybe I'm affected by the way grails works with the
>>> model!
>>>
>>
>> Interesting. Do you know what advantages that brings to Grails?
>>
>> Well as I said I'm affected. That doesn't mean that there is so
>> much advantages or there isn't any workaround on this or even that
>> this is the way it should be. But most times I don't have only one
>> model per page. This is true for stuff like xml and json responses
>> but in most cases when dealing with html responses (witch is the
>> case of most of the webapps) you will have to also include other
>> resources and use many models per request.
>>
>> Of course you can create your jaxrs classes to provide you with the
>> model you may need (so you can do a it.somemodel) with getters (and
>> use inheritance and composition for complex pages witch would need
>> complex model) or create a map with all the stuff you need and pass
>> this map as a model. You can even then tweak the map instead of
>> creating new one for other included resources.
>>
>> The only problem is that java is not so expressive and a creation
>> of a map just to pass a model to the view isn't very clean. I mean
>> consider:
>>
>> Map model = new HashMap()
>> model.put('key1', somevalue1)
>> model.put('key2', somevalue2)
>> model.put('key3', somevalue3)
>> return new Viewable(path, model)
>>
>> to the grails/groovy equivalent:
>> return [key1:somevalue1, key2:somevalue2, key3:somevalue3]
>>
>
> OK. Note that you can use Groovy with JAX-RS and Jersey.
>
>
>> At last I don't find really handy the use of 'it' inside the views.
>> For example when you have to deal with books in a bookstore, using
>> BookList as your model name would be really helpful for anyone
>> reading the jsp to understand that has to probably deal with a List
>> of Books (List<Book>)
>>
>
> Good point.
>
>
>> Of course I find much more cleaner and easier to use the way jersey
>> (and generally jaxrs implementation) deal with url mapping than
>> grails does, and this a reason using it!
>>
>> I can understand that these issues doesn't have anything to do with
>> JAXRS directly, but if someone want to use it as a web framework
>> and not just an easy way to communicate with xml, I think that
>> stuff like that matters. By the way am I the only one that uses
>> jersey as a web framework?
>>
>
> No. I am actually surprised at the level of use given that degree of
> documentation and time spent on it :-) We have not focused enough
> resources on this area but i believe it holds a lot of promise.
>
>
>>
>>
>> From your initial proposal i understand that model naming is
>> required so that models from different views do not conflict. If we
>> can avoid such a conflict by other means then what advantages would
>> such naming give us?
>>
>>
>> As you can understand it is not a workaround in order for my
>> initial proposal to work right! It is something that I thing will
>> help the expressiveness of the view mechanism as is right now. That
>> doesn't mean that is the way to go. I would really like to hear
>> opinions from people using the jersey on that. It is not something
>> that you can't do with it, but I'm sure anyone will benefit from
>> such an improvement.
>
>
> OK.
>
> Paul.