I think that I've also included a tweaked version of the jersey's Servlet
class. I modified just the filter method, and used jersey as a filter and
not a servlet. I can have a look at it today when I'll get back home. I've
played a lot with the whole situation and don't really remember witch
version of the project I've attached.
At last a forward call on the requestdispatcher will fail if the container
have send some data to the user already. This means if you use the forward
method within a jsp it will most likely fail. For inclusion we you *must*
use the include method of the requestdispatcher.
I'll revision the attachment today. Of course If you have anything more on
that, just include them to have a look!
Regards,
Yoryos
On Tue, Dec 15, 2009 at 13:06, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> 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.
>
>
>