doView(), but not send back all the portal wrapper HTML

[jkancianic]

We're using Ajax with the portal. We see examples of how to use servlets to handle Ajax requests and got that working, but we would prefer to have Ajax just call the associated portlet's actionURL and have the portlet generate the little HTML fragment we want our div tag to be populated with.

Right now, the doView method send us to the .jsp file we want, but it includes all the extra portal wrapper HTML around it, such as the header portion of the page. We get a portal-within-a-portlet-within-a-portal effect. This is expected because of the default rendering model.

Is there a way to have the doView() method sometimes just forward to the wanted .jsp file results so that only that .jsp-generated content is sent back? i.e. just don't add the rest of the portal-provided decorations.

I think there may be tools in the portal code that can do things we need, but am struggling with knowing what options/features are available because there is a lack of documentation linking it all together.

[mholzner]

the samples contain an AJAX portlet that you can take a look at.

There are some steps in th 2.4 code base to get things like a region or a single portlet window to be rendered via AJAX requests, but its from complete.

[smoyer]

DISCLAIMER - I HAVE NOT TRIED THIS YET!

I have a similar requirement and have been considering ways to force the Portlet to use the emptyRenderer for certain requests ... is this a sane way to accomplish what jkancianic has asked?

[mholzner]

it won't get you all the way. The render set only takes over at the region level, the layout still renders the the HTML and body tag, etc.

If you look at the 2.4 code base there are MarkupCommands for Page, Region and Window (Region and Window are untested at this point). Those commands are rendering what you need (at least in theory ;) ;
What's missing are the URLFactory and the CommandFactory to map between URLs and Commands, and a sane way to get the URLs into the rendered markup.....

Feel free to take a look, I won't get to it in the next 3 weeks.

[jkancianic]

I was concerned that with the servlet method, you might lose some of the features that you get going through the portlet, such as having access to the session (and it being kept alive), security checking, etc.

If you still have these things happening with the servlet, then I'm not as worried about it right now.

Anyone have comments as to my concern or is it not an issue - the servlets have the same features?

[mholzner]

what I am describing would use the same servlet as the full page render process. It's a dfferent path in the core invocation stack, effectively choosing another render command based on the URL that caused the request, but that's it, the rest of the invocation would be the same (i.e. same servlet, same security context, same entry point, hence security checks , etc)

But as I said: it's not there yet (only in a somewhat undigested form in my head ;)

[jkancianic]

Thanks everyone for reacting to my questions.

Is my assumption correct - If we just use the servlet method described in the AJAX portlet example that's in the portlet repository collection right now: do we not have the same environment and resulting portal framework features that I listed above than if you accessed a portlet the "regular" way, i.e. going through processaction(), then doView()?