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 11:56:59 +0100

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);
     }

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.