portals-jetspeed-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Gardner" <bgardne...@gmail.com>
Subject Re: Default Portlet State
Date Wed, 16 Apr 2008 22:23:53 GMT
update:

I was able to go out and check the API, and from what it looks like, the
DispatcherPortlet does (through 2 other classes) inherit its doView from
GenericPortlet, so to override it properly, you should make it public as
opposed to protected.

On Wed, Apr 16, 2008 at 6:11 PM, Brad Gardner <bgardner87@gmail.com> wrote:

> I haven't looked at the spring implementation that you are extending, but
> coming from GenericPortlet, it's usually "public void doView" instead of
> protected.
>
>
> On Wed, Apr 16, 2008 at 4:59 PM, Dan Olsen <danrolsen@utah.gov> wrote:
>
> > Below is the code for my class that is overriding DispatcherPortlet. Any
> > signs of what the problem might be that is causing the doView not to be
> > invoked?
> >
> > /**
> >  * @author DOLSEN
> >  *
> >  */
> > public class PerformanceManagementPortlet extends DispatcherPortlet {
> >    String firstView;
> >
> >    @Override
> >    public void init(PortletConfig config) throws PortletException {
> >        super.init(config);
> >        this.firstView = config.getInitParameter("firstView");
> >    }
> >
> >    @Override
> >    protected void doView(RenderRequest request, RenderResponse response)
> >                     throws PortletException, IOException {
> >        response.setContentType("text/html");
> >        response.getWriter().write("Start: " + this.firstView);
> >    }
> >
> > }
> >
> >
> > >>> "Andrew Strickland" <strickla@gmail.com> 4/16/2008 2:43 PM >>>
> > Could be a number of reasons...
> >
> > Check to make sure you've overridden the method properly including
> > having the parameters passed in the same order as the
> > superclass...otherwise you'll just have a very "similar" method.
> > Swapping the order of the parameters is a common mistake.  If you're
> > using an IDE that does auto-overide or auto-implementation for you
> > then I would think this isn't that likely but if you did it by hand
> > then it could happen.
> >
> > Make sure you're not calling super.doView(...) at the beginning of
> > your method.  First you want to do your window state management, and
> > THEN call super.doView(...) at the end.  If you call it at the
> > beginning then the super method is almost assuredly returning and
> > writing to the outputstream before you get the chance to set the
> > window state.
> >
> > Make sure your portlet.xml is using your new extended class and not
> > the Spring portlet class.
> >
> > Any further guesses would be just that.  If you can provide the code
> > of your overridden doView it might shed more light.
> >
> > On Wed, Apr 16, 2008 at 4:35 PM, Dan Olsen <danrolsen@utah.gov> wrote:
> > > So I have created a class that extends the DispatcherPortlet class.
> > However, for some reason my doView function is not being invoked. I overrode
> > the init function and that is getting invoked. Any idea why my doView
> > function would not be getting invoked?
> > >
> > >  - Dan
> > >
> > >  >>> "Andrew Strickland" <strickla@gmail.com> 4/15/2008 10:11
AM >>>
> > >
> > >
> > > So create your own portlet class that extends
> > >  org.springframework.web.portlet.DispatcherPortlet.
> > >  and override the doView to do the same as the Spring portlet but
> > modify to
> > >  add in your handling of the default view state.
> > >
> > >
> > >  On Tue, Apr 15, 2008 at 11:59 AM, Dan Olsen <danrolsen@utah.gov>
> > wrote:
> > >
> > >  > The problem for me is that I am using Spring to create my portlets.
> > So the
> > >  > class pointed to in my portlet.xml file is
> > >  > org.springframework.web.portlet.DispatcherPortlet.
> > >  >
> > >  > >>> "Andrew Strickland" <strickla@gmail.com> 4/15/2008
8:48 AM >>>
> > >  > If "*firstView*" is true set window state to minimized and then set
> > "*
> > >  > firstView*" to false, then render...subsequent doViews will check
> > the
> > >  > value
> > >  > of "*firstView*" (it's now false) and will render with whatever
> > window
> > >  > state
> > >  > the portal tells it to render with.
> > >  >
> > >  > On Tue, Apr 15, 2008 at 10:43 AM, Dan Olsen <danrolsen@utah.gov>
> > wrote:
> > >  >
> > >  > > But won't this solution render it closed every time it renders?
> > It would
> > >  > > make sense if there was a setting for portlets to set the default
> > window
> > >  > > state.
> > >  > >
> > >  > > >>> "Andrew Strickland" <strickla@gmail.com> 4/14/2008
6:16 PM
> > >>>
> > >  > > He means default to minizmized window state.  I've tried to
> > answer this
> > >  > > question twice before...I believe the best possible solution is:
> > >  > >
> > >  > > 1) add an init parameter to your portlet.xml like "firstView" and
> > set it
> > >  > > to
> > >  > > true.  In your portlet class's doRender method check the value of
> > the
> > >  > > initParmater.  If it's true, set window state to minimized and
> > >  > render...if
> > >  > > it's false then do nothing to window state and render.
> > >  > >
> > >  > > Andy
> > >  > >
> > >  > > On Mon, Apr 14, 2008 at 7:11 PM, David Sean Taylor <
> > >  > david@bluesunrise.com>
> > >  > > wrote:
> > >  > >
> > >  > > >
> > >  > > > On Apr 14, 2008, at 2:56 PM, Dan Olsen wrote:
> > >  > > >
> > >  > > >  ** High Priority **
> > >  > > > >
> > >  > > > > I am still not sure how to default all portlets to closed
> > when a
> > >  > user
> > >  > > > > logs in. I have a demo coming up to show the client what
I
> > have done
> > >  > > so far
> > >  > > > > and we would really like to have the portlets defaulting
to
> > closed.
> > >  > > Can
> > >  > > > > someone please help me figure this out?
> > >  > > > >
> > >  > > > > I would figured this would be an easy task but I have
yet to
> > find
> > >  > any
> > >  > > > > way to make this happen. I really need to get this figured
> > out so
> > >  > any
> > >  > > help
> > >  > > > > would be greatly appreciated.
> > >  > > > >
> > >  > > >
> > >  > > > Is this for Jetspeed 1.x ?
> > >  > > > Not sure what you mean by "closed"
> > >  > > >
> > >  > > >
> > >  > > >
> > >  > > >
> > ---------------------------------------------------------------------
> > >  > > > To unsubscribe, e-mail:
> > jetspeed-user-unsubscribe@portals.apache.org
> > >  > > > For additional commands, e-mail:
> > jetspeed-user-help@portals.apache.org
> > >  > > >
> > >  > > >
> > >  > >
> > >  >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> >
> >
>
>
> --
> Brad Gardner




-- 
Brad Gardner

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message