Yes, sorry for not responsing sooner myself, but looks like we have
agreement on Plan B :-) Ate, please let us know when the code is
updated and a new release can be made.
Thanks, Jason
Ate Douma wrote:
Stefan Hepper wrote:
Ate Douma <[EMAIL PROTECTED]> wrote on 29/07/2005 16:05:20:
Jason Novotny wrote:
Cool-- I appreciate your work in this area! Developing standards
compliant briodges that we as portal vendors can use will greatly
enhance all of our projects as well as give people confidence in
developing solutions that avoid vendor lock-in-- kep up the great work
:-)
Thanks :-)
I'm inlining your original question here so others will understand what
this
is all about. And also cc'ing Stefan and jsr-168-comments as I'd
like to provide
a solution that is acceptable (as much as possible) to all.
Thanks for including me on this thread.
Thanks for responding :-)
Jason Novotny wrote:
>
> Hi Ate,
>
> Great work on the struts portlet brige! I'm trying to heist the
code
> and get it working in GridSphere. I just used the struts-demo and it
all
> worked fine with the right tweaks in web.xml and using our
> PortletServlet driver. Not too sure how that app really works ;-) but
> navigation and form handling seem to work fine. One issue I had
though
> where I had to change my code is make sure to add the
> "javax.portlet.request" attribute in the request since some the
bridge
> code uses a check like:
>
> public static boolean isPortletRequest(ServletRequest request)
> {
> return request.getAttribute("javax.portlet.request") != null;
> }
>
> But it seems according to the spec. that it shouldn't need to be set
> before performing an action method, since the RenderRequest which
> represents "javax.portlet.request" PLT 16.3.2 would only be
accessible
> when a servlet is included as part of a render request... but I can't
> really come up with any other way that would indicate that it's a
> portlet request.
>
> Cheers, Jason
>
>
I gave this problem some more thought.
Its true that the portlet api doesn't specify anything about setting
the javax.portlet.* attributes during ActionRequest handling.
It would also not make sense, because the spec states that the
request is
the render request that is included.
But then, the spec doesn't (formally) support Servlet inclusion from
an ActionRequest
either (which is a *big* omission in my opinion).
It was discussed, but there was no consensus at that time to include
this
in the spec. Something we may bring up for V2.0 again.
That indeed would be nice. Any info when that might be? ;-)
So, using the Struts Bridge (or more specific: the Portals Bridges
Common ServletContextProvider interface)
is already not fully in compliance with JSR-168. But then, I don't
think its in violation either.
It just requires access to the underlying Servlet context.
But *not* that a Portlet request extends the Servlet request as
Stefan Hepper thought.
good to hear, but still it will be vendor specifc how you get the
servlet
context and thus for each portal there would need to be an
implementation
on how to access the servlet context.
True.
That's why I created one simple interface: ServletContextProvider which
indeed need to be implemented by (or for) a specific Portal.
But then, that's the only thing required. The Struts Bridge (and other
bridges
using this as well) have no further dependency on a specific Portal.
Now, I see two ways to solve this problem:
a) use a different request attribute to test against, like
StrutsPortlet.REQUEST_TYPE
b) actually set this attribute (and the others) from StrutsPortlet.
processRequest before
including the StrutsServlet when handling an ActionRequest.
Solution a) is quick and simple to do as this request attribute
already is set when the StrutsServlet
is invoked from StrutsPortlet.
Solution b) might be more generic though.
This way, Portals are not required to set these attributes (won't
harm either, Jetspeed-2 itself *does* set these).
And, the Struts application has an easy and *transparent* access to
the PortletRequest/Response/Config
components, even during ActionRequest handling. These attributes
then are guaranteed to exist when using the Struts
Bridge, independent of the underlying Portal.
This might be an "extension" of the portlet specs, but I don't think
it is a violation.
I certainly would like to see something like this (and the
ServletContextProvider)
supported in an upcoming spec update :-)
Clearly I prefer solution b). What do you think?
I agree that B would be the solution that does not make any assumptions
beyond the portlet spec about the calling portal.
Neither does option A, but good you don't see any problem going for B :-)
Thanks again.
Regards, Ate
Regards,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
