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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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" <[EMAIL PROTECTED]> 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 <
> > > [EMAIL PROTECTED]>
> > > > 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:
> [EMAIL PROTECTED]
> > > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Brad Gardner
