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.
> 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.
> 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.
> 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.
Regards,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
