You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Nick Lothian <nl...@essential.com.au> on 2004/02/03 23:23:47 UTC
FW: [PATCH] RE: Customisation of Pluto Portal
I'm resending this because everyone was too busy to look at it last time.
Sorry to be a pain, but I really need this functionality in the Pluto
Portal.
-----Original Message-----
From: Nick Lothian [mailto:nl@essential.com.au]
Sent: Friday, 23 January 2004 4:36 PM
To: pluto-dev@jakarta.apache.org
Subject: [PATCH] RE: Customisation of Pluto Portal
PortletFragmentFooter.jsp and PortletFragmentHeader.jsp go in
WEB-INF/aggregation
There are a couple of fairly minor changes in PortletFragmentHeader.jsp
compared to the old portlet code I should point out:
1) All Portlet Modes are displayed (not just the non-active ones), but only
the non-active ones have a link.
2) All Window States are displayed (not just the non-active ones), but only
the non-active ones have a link.
3) There is a " | " between the Portlet Modes and the Window States.
4) I didn't include the code
writer.println("<a
name="+thisURL.getLocalNavigationAsString()+"></a>"); doesn't work (and
doesn't include quotes, either)
because it didn't actually work (missing quotes around the name, and
thisURL.getLocalNavigationAsString() always seems to appear blank.
Apart from that, the Portlets should appear identical to before.
Any comments?
> -----Original Message-----
> From: Nick Lothian [mailto:nl@essential.com.au]
> Sent: Friday, 23 January 2004 10:32 AM
> To: pluto-dev@jakarta.apache.org
> Subject: RE: Customisation of Pluto Portal
> Importance: Low
>
>
> I'm currently doing this change, and I have a couple of
> questions about
> org.apache.pluto.portalImpl.aggregation.PortletFragment
>
> (See
> <http://cvs.apache.org/viewcvs.cgi/jakarta-pluto/portal/src/ja
> va/org/apache/
> pluto/portalImpl/aggregation/PortletFragment.java?rev=1.2&only
> _with_tag=3DHEAD
> &view=markup> if you don't have the code handy).
>
> I've done a basic implementation of what I want, and now I'm
> looking at
> error handling. Currently the code catches Throwable in a
> couple of places,
> prints the stack-trace to System.err and attempts to continue.
>
> I believe the motivation for this is probably to try and stop
> problems in
> one Portlet from taking down the whole Portal, which makes sense.
>
> However, I'm not convinced about the practice of catching and silently
> swallowing Throwable.
>
> What I propose is this:
>
> 1) For all exceptions, to attempt to output a "error occurred
> in portlet"
> message in between the header and footer of the portlet, so
> it won't effect
> other portlets on the same page. Obviously this won't work
> all the time - if
> the footer JSP page throws an exception then it will probably
> effect the
> rest of the portal.
>
> 2) To catch Throwable, log it, and handle it as an Exception
> unless it is an
> instanceof VirtualMachineError, in which case I will re-throw it.
>
> Thoughts?
>
> > -----Original Message-----
> > From: Nick Lothian [mailto:nl@essential.com.au]
> > Sent: Tuesday, 20 January 2004 11:56 AM
> > To: pluto-dev@jakarta.apache.org
> > Subject: Customisation of Pluto Portal
> > Importance: Low
> >
> >
> >
> > I'd like it if the Pluto Portal was a little more flexible in
> > the visual
> > appearance of the Pluto portal. I understand that this portal
> > isn't designed
> > for production use (etc, etc), but there is one specific
> > changes I'd like
> > that would make it a lot more flexible for me.
> >
> > I'd like the hard-coded mark-up in
> > org.apache.pluto.portalImpl.aggregation.PortletFragment to be
> > moved into JSP
> > pages in a similar way to the way in which the aggregation
> > JSP pages work.
> > I'd suggest a header and footer JSP page would be sufficient.
> >
> > If that isn't possible, I'd like a factory to specify what
> > implementation of
> > org.apache.pluto.portalImpl.aggregation.Fragment the Portal
> would use.
> >
> > I would have thought option one would be relatively easy.
> I'm happy to
> > submit patches for it (the first option) if people think it
> > is a good idea.
> >
> > Nick
> >
>
Re: FW: [PATCH] RE: Customisation of Pluto Portal
Posted by Michael Blum <bl...@apache.org>.
Nick, I think that this approach (option one) improves customization of
the portal. I committed your patches.
Michael
Nick Lothian wrote:
>I'm resending this because everyone was too busy to look at it last time.
>
>Sorry to be a pain, but I really need this functionality in the Pluto
>Portal.
>
>-----Original Message-----
>From: Nick Lothian [mailto:nl@essential.com.au]
>Sent: Friday, 23 January 2004 4:36 PM
>To: pluto-dev@jakarta.apache.org
>Subject: [PATCH] RE: Customisation of Pluto Portal
>
>
>PortletFragmentFooter.jsp and PortletFragmentHeader.jsp go in
>WEB-INF/aggregation
>
>There are a couple of fairly minor changes in PortletFragmentHeader.jsp
>compared to the old portlet code I should point out:
>
>1) All Portlet Modes are displayed (not just the non-active ones), but only
>the non-active ones have a link.
>2) All Window States are displayed (not just the non-active ones), but only
>the non-active ones have a link.
>3) There is a " | " between the Portlet Modes and the Window States.
>4) I didn't include the code
> writer.println("<a
>name="+thisURL.getLocalNavigationAsString()+"></a>"); doesn't work (and
>doesn't include quotes, either)
> because it didn't actually work (missing quotes around the name, and
>thisURL.getLocalNavigationAsString() always seems to appear blank.
>
>Apart from that, the Portlets should appear identical to before.
>
>Any comments?
>
>
>
>
>>-----Original Message-----
>>From: Nick Lothian [mailto:nl@essential.com.au]
>>Sent: Friday, 23 January 2004 10:32 AM
>>To: pluto-dev@jakarta.apache.org
>>Subject: RE: Customisation of Pluto Portal
>>Importance: Low
>>
>>
>>I'm currently doing this change, and I have a couple of
>>questions about
>>org.apache.pluto.portalImpl.aggregation.PortletFragment
>>
>>(See
>><http://cvs.apache.org/viewcvs.cgi/jakarta-pluto/portal/src/ja
>>va/org/apache/
>>pluto/portalImpl/aggregation/PortletFragment.java?rev=1.2&only
>>_with_tag=3DHEAD
>>&view=markup> if you don't have the code handy).
>>
>>I've done a basic implementation of what I want, and now I'm
>>looking at
>>error handling. Currently the code catches Throwable in a
>>couple of places,
>>prints the stack-trace to System.err and attempts to continue.
>>
>>I believe the motivation for this is probably to try and stop
>>problems in
>>one Portlet from taking down the whole Portal, which makes sense.
>>
>>However, I'm not convinced about the practice of catching and silently
>>swallowing Throwable.
>>
>>What I propose is this:
>>
>>1) For all exceptions, to attempt to output a "error occurred
>>in portlet"
>>message in between the header and footer of the portlet, so
>>it won't effect
>>other portlets on the same page. Obviously this won't work
>>all the time - if
>>the footer JSP page throws an exception then it will probably
>>effect the
>>rest of the portal.
>>
>>2) To catch Throwable, log it, and handle it as an Exception
>>unless it is an
>>instanceof VirtualMachineError, in which case I will re-throw it.
>>
>>Thoughts?
>>
>>
>>
>>>-----Original Message-----
>>>From: Nick Lothian [mailto:nl@essential.com.au]
>>>Sent: Tuesday, 20 January 2004 11:56 AM
>>>To: pluto-dev@jakarta.apache.org
>>>Subject: Customisation of Pluto Portal
>>>Importance: Low
>>>
>>>
>>>
>>>I'd like it if the Pluto Portal was a little more flexible in
>>>the visual
>>>appearance of the Pluto portal. I understand that this portal
>>>isn't designed
>>>for production use (etc, etc), but there is one specific
>>>changes I'd like
>>>that would make it a lot more flexible for me.
>>>
>>>I'd like the hard-coded mark-up in
>>>org.apache.pluto.portalImpl.aggregation.PortletFragment to be
>>>moved into JSP
>>>pages in a similar way to the way in which the aggregation
>>>JSP pages work.
>>>I'd suggest a header and footer JSP page would be sufficient.
>>>
>>>If that isn't possible, I'd like a factory to specify what
>>>implementation of
>>>org.apache.pluto.portalImpl.aggregation.Fragment the Portal
>>>
>>>
>>would use.
>>
>>
>>>I would have thought option one would be relatively easy.
>>>
>>>
>>I'm happy to
>>
>>
>>>submit patches for it (the first option) if people think it
>>>is a good idea.
>>>
>>>Nick
>>>
>>>
>>>
>
>
>