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 Gonzalo Aguilar Delgado <ga...@aguilardelgado.com> on 2009/05/29 11:11:01 UTC
Display empty portal
Hi everyone.
I see that when PortletWindowImpl does not find a portlet a Exception is
returned to the PortletTag class.
This means that whole portal stops because can't render anything.
I'm writing a small patch for this.
I can handle this several ways but two of them seem meaningful:
1.- Implement a custom portlet that will be rendered when the
requested one is not available.
This portlet will handle the situation and show a small message
saying that the portlet is not available.
While this is a good solution if something bad happens
and this portlet is also not available we will se again
the main crash of the portal.
2.- Implement a special renderer that will render the message
directly from the container.
Is there any useful solution?
What do you think it's best?
Thank you.
____________________________________
Gonzalo Aguilar Delgado
Consultor CRM - Ingeniero en
Informática
M. +34 607814276
Re: Display empty portal
Posted by Ate Douma <at...@douma.nu>.
Gonzalo Aguilar Delgado wrote:
>
> Hi Ate,
>
> Patch is sent.
I just replied to it on the issue itself.
>
> About your guidelines... You convinced me. I will give a try to the
> Jetspeed2 again. But surely I will strip it out as you said.
>
> Thank you very much for your time.
>
> I will keep an eye to the Pluto project and also will join to the
> Jetspeed2.
Welcome on board :)
>
>
> I hope I can help as much as the community helped me.
Great, looking forward to it.
Regards,
Ate
>
> Thank you again.
>
>
>
>
>
Re: Display empty portal
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
El vie, 29-05-2009 a las 12:28 +0200, Ate Douma escribió:
> Gonzalo Aguilar Delgado wrote:
> > El vie, 29-05-2009 a las 11:28 +0200, Ate Douma escribió:
> >> Gonzalo Aguilar Delgado wrote:
> >>> Hi everyone.
> >>>
> >>> I see that when PortletWindowImpl does not find a portlet a Exception is
> >>> returned to the PortletTag class.
> >>>
> >>> This means that whole portal stops because can't render anything.
> >>>
> >>> I'm writing a small patch for this.
> >>>
> >>> I can handle this several ways but two of them seem meaningful:
> >>>
> >>> 1.- Implement a custom portlet that will be rendered when the
> >>> requested one is not available.
> >>> This portlet will handle the situation and show a small message
> >>> saying that the portlet is not available.
> >>> While this is a good solution if something bad happens
> >>> and this portlet is also not available we will se again
> >>> the main crash of the portal.
> >>>
> >>> 2.- Implement a special renderer that will render the message
> >>> directly from the container.
> >>>
> >>> Is there any useful solution?
> >>>
> >>> What do you think it's best?
> >> In Jetspeed-2 we handle this by capturing all container invocation errors and either returning an appropriate (pluggable/configurable) error
> >> page for non-rendering processing (Action/Event/Resource), or display an appropriate message within the PortletWindow instead.
> >>
> >> For Pluto Portal this might require some extensive changes to do something similar, which in that case might be out-of-scope for the purpose
> >> of Pluto Portal itself (if doable with a small fix/patch would be fine however).
> >>
> >> Be aware that Pluto Portal is not written for nor targeted at real production usage: its primary and only purpose is to provide a testbed
> >> environment for the Pluto Container.
> >> If you want to expand upon the Pluto Portal yourself, you might be looking at some major rewriting to get it to acceptable quality level
> >> (for that purpose).
> >> If you really need a production ready Portal I suggest looking at Jetspeed-2 Portal instead.
> >>
> >> Regards,
> >>
> >> Ate
> >>
> >>> Thank you.
> >
> > Hi Ate,
> >
> > I will work 100% of time on this project. So enough effort will be set
> > for this. I don't know if doing it all it's out-of-scope but I already
> > tried Jetspeed-2, liferay, Sun Portal (based on liferay), etc. And as
> > you say JetSpeed is by far the fastest one. I want a lightweight portal
> > with some enhancements but not much complex.
> >
> >
> > When I checked Jetspeed2 the JSR-286 was not available and this was
> > unacceptable for my purpose. (With v. 2.2.0 I will give it a try again.)
>
> Please do check Jetspeed-2 v 2.2.0 now, we support all the features from Pluto 2.0.0 *and* more!
> Furthermore, Jetspeed-2 is extremely customizable so you can easily "strip out" features you don't need or want to replace.
>
> >
> > But the question is that I want to bring several features to the portals
> > like ajax rendering via dojo and DWR handlers, stable hot application
> > deployment, and speed. And also I don't like much Velocity.
> Jetspeed does use dojo already and we has some nice Ajax header contribution handling for that as well.
> This has been made generic and example (base) portlet support is provided through the Portals Applications gems component.
> See: http://portals.apache.org/applications/portals-gems/index.html
> and: http://svn.apache.org/repos/asf/portals/applications/gems/trunk/src/main/java/org/apache/portals/gems/dojo
>
> >
> > I saw that jetSpeed is on the way to implement ajax and some other great
> > things. So I'm in doubt about extending Pluto to make it enterprise
> > enabled. Extend jetspeed2. Or fork from jetspeed or pluto.
>
> If you want (and can) work together with us adding/extending features like these on basis of ASF licensed contribution,
> your help would be very welcome and we definitely are interested.
>
> >
> > Don't know what to do but I want to do it.
> >
> > But at least Pluto let's me understand what's going on and prepare some
> > demos.
> I think while Pluto Portal is very lightweight and quick to use, once you get familiar with Jetspeed-2 I can assure you
> you'll find a much better support for development and deployment of these kind of features, as well as more direct and active support from
> the Portals committers too.
>
> >
> > If you can give me some directions they are going to be really welcome.
> Best advise would first to start setting up your own (custom) Jetspeed 2.2.0 portal and play around with it for a while.
> You can start with the new Jetspeed-2 build guide: http://portals.apache.org/jetspeed-2/buildguide/index.html
> and then progress through the other guides online: http://portals.apache.org/jetspeed-2/getting-started.html
>
> If you hit the unknown or have questions, just ask them on the jetspeed-dev or jetspeed-user lists, and we'll be glad to help you out further.
>
> >
> > About the patch. I already did a patch that will show at least the
> > portlet with a small message. just modified the taglib a little bit and
> > the container.
> >
> > Do you want the patch to be sent?
> Sure, for this case I think creating a JIRA issue is appropriate and attach the patch there.
> I'll review it and let you know if it is applicable and in-scope or not.
>
> Regards,
>
> Ate
>
> >
> > Thank you in advance.
Hi Ate,
Patch is sent.
About your guidelines... You convinced me. I will give a try to the
Jetspeed2 again. But surely I will strip it out as you said.
Thank you very much for your time.
I will keep an eye to the Pluto project and also will join to the
Jetspeed2.
I hope I can help as much as the community helped me.
Thank you again.
Re: Display empty portal
Posted by Ate Douma <at...@douma.nu>.
Gonzalo Aguilar Delgado wrote:
> El vie, 29-05-2009 a las 11:28 +0200, Ate Douma escribió:
>> Gonzalo Aguilar Delgado wrote:
>>> Hi everyone.
>>>
>>> I see that when PortletWindowImpl does not find a portlet a Exception is
>>> returned to the PortletTag class.
>>>
>>> This means that whole portal stops because can't render anything.
>>>
>>> I'm writing a small patch for this.
>>>
>>> I can handle this several ways but two of them seem meaningful:
>>>
>>> 1.- Implement a custom portlet that will be rendered when the
>>> requested one is not available.
>>> This portlet will handle the situation and show a small message
>>> saying that the portlet is not available.
>>> While this is a good solution if something bad happens
>>> and this portlet is also not available we will se again
>>> the main crash of the portal.
>>>
>>> 2.- Implement a special renderer that will render the message
>>> directly from the container.
>>>
>>> Is there any useful solution?
>>>
>>> What do you think it's best?
>> In Jetspeed-2 we handle this by capturing all container invocation errors and either returning an appropriate (pluggable/configurable) error
>> page for non-rendering processing (Action/Event/Resource), or display an appropriate message within the PortletWindow instead.
>>
>> For Pluto Portal this might require some extensive changes to do something similar, which in that case might be out-of-scope for the purpose
>> of Pluto Portal itself (if doable with a small fix/patch would be fine however).
>>
>> Be aware that Pluto Portal is not written for nor targeted at real production usage: its primary and only purpose is to provide a testbed
>> environment for the Pluto Container.
>> If you want to expand upon the Pluto Portal yourself, you might be looking at some major rewriting to get it to acceptable quality level
>> (for that purpose).
>> If you really need a production ready Portal I suggest looking at Jetspeed-2 Portal instead.
>>
>> Regards,
>>
>> Ate
>>
>>> Thank you.
>
> Hi Ate,
>
> I will work 100% of time on this project. So enough effort will be set
> for this. I don't know if doing it all it's out-of-scope but I already
> tried Jetspeed-2, liferay, Sun Portal (based on liferay), etc. And as
> you say JetSpeed is by far the fastest one. I want a lightweight portal
> with some enhancements but not much complex.
>
>
> When I checked Jetspeed2 the JSR-286 was not available and this was
> unacceptable for my purpose. (With v. 2.2.0 I will give it a try again.)
Please do check Jetspeed-2 v 2.2.0 now, we support all the features from Pluto 2.0.0 *and* more!
Furthermore, Jetspeed-2 is extremely customizable so you can easily "strip out" features you don't need or want to replace.
>
> But the question is that I want to bring several features to the portals
> like ajax rendering via dojo and DWR handlers, stable hot application
> deployment, and speed. And also I don't like much Velocity.
Jetspeed does use dojo already and we has some nice Ajax header contribution handling for that as well.
This has been made generic and example (base) portlet support is provided through the Portals Applications gems component.
See: http://portals.apache.org/applications/portals-gems/index.html
and: http://svn.apache.org/repos/asf/portals/applications/gems/trunk/src/main/java/org/apache/portals/gems/dojo
>
> I saw that jetSpeed is on the way to implement ajax and some other great
> things. So I'm in doubt about extending Pluto to make it enterprise
> enabled. Extend jetspeed2. Or fork from jetspeed or pluto.
If you want (and can) work together with us adding/extending features like these on basis of ASF licensed contribution,
your help would be very welcome and we definitely are interested.
>
> Don't know what to do but I want to do it.
>
> But at least Pluto let's me understand what's going on and prepare some
> demos.
I think while Pluto Portal is very lightweight and quick to use, once you get familiar with Jetspeed-2 I can assure you
you'll find a much better support for development and deployment of these kind of features, as well as more direct and active support from
the Portals committers too.
>
> If you can give me some directions they are going to be really welcome.
Best advise would first to start setting up your own (custom) Jetspeed 2.2.0 portal and play around with it for a while.
You can start with the new Jetspeed-2 build guide: http://portals.apache.org/jetspeed-2/buildguide/index.html
and then progress through the other guides online: http://portals.apache.org/jetspeed-2/getting-started.html
If you hit the unknown or have questions, just ask them on the jetspeed-dev or jetspeed-user lists, and we'll be glad to help you out further.
>
> About the patch. I already did a patch that will show at least the
> portlet with a small message. just modified the taglib a little bit and
> the container.
>
> Do you want the patch to be sent?
Sure, for this case I think creating a JIRA issue is appropriate and attach the patch there.
I'll review it and let you know if it is applicable and in-scope or not.
Regards,
Ate
>
> Thank you in advance.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Display empty portal
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
El vie, 29-05-2009 a las 11:28 +0200, Ate Douma escribió:
> Gonzalo Aguilar Delgado wrote:
> > Hi everyone.
> >
> > I see that when PortletWindowImpl does not find a portlet a Exception is
> > returned to the PortletTag class.
> >
> > This means that whole portal stops because can't render anything.
> >
> > I'm writing a small patch for this.
> >
> > I can handle this several ways but two of them seem meaningful:
> >
> > 1.- Implement a custom portlet that will be rendered when the
> > requested one is not available.
> > This portlet will handle the situation and show a small message
> > saying that the portlet is not available.
> > While this is a good solution if something bad happens
> > and this portlet is also not available we will se again
> > the main crash of the portal.
> >
> > 2.- Implement a special renderer that will render the message
> > directly from the container.
> >
> > Is there any useful solution?
> >
> > What do you think it's best?
>
> In Jetspeed-2 we handle this by capturing all container invocation errors and either returning an appropriate (pluggable/configurable) error
> page for non-rendering processing (Action/Event/Resource), or display an appropriate message within the PortletWindow instead.
>
> For Pluto Portal this might require some extensive changes to do something similar, which in that case might be out-of-scope for the purpose
> of Pluto Portal itself (if doable with a small fix/patch would be fine however).
>
> Be aware that Pluto Portal is not written for nor targeted at real production usage: its primary and only purpose is to provide a testbed
> environment for the Pluto Container.
> If you want to expand upon the Pluto Portal yourself, you might be looking at some major rewriting to get it to acceptable quality level
> (for that purpose).
> If you really need a production ready Portal I suggest looking at Jetspeed-2 Portal instead.
>
> Regards,
>
> Ate
>
> >
> > Thank you.
Hi Ate,
I will work 100% of time on this project. So enough effort will be set
for this. I don't know if doing it all it's out-of-scope but I already
tried Jetspeed-2, liferay, Sun Portal (based on liferay), etc. And as
you say JetSpeed is by far the fastest one. I want a lightweight portal
with some enhancements but not much complex.
When I checked Jetspeed2 the JSR-286 was not available and this was
unacceptable for my purpose. (With v. 2.2.0 I will give it a try again.)
But the question is that I want to bring several features to the portals
like ajax rendering via dojo and DWR handlers, stable hot application
deployment, and speed. And also I don't like much Velocity.
I saw that jetSpeed is on the way to implement ajax and some other great
things. So I'm in doubt about extending Pluto to make it enterprise
enabled. Extend jetspeed2. Or fork from jetspeed or pluto.
Don't know what to do but I want to do it.
But at least Pluto let's me understand what's going on and prepare some
demos.
If you can give me some directions they are going to be really welcome.
About the patch. I already did a patch that will show at least the
portlet with a small message. just modified the taglib a little bit and
the container.
Do you want the patch to be sent?
Thank you in advance.
Re: Display empty portal
Posted by Ate Douma <at...@douma.nu>.
Gonzalo Aguilar Delgado wrote:
> Hi everyone.
>
> I see that when PortletWindowImpl does not find a portlet a Exception is
> returned to the PortletTag class.
>
> This means that whole portal stops because can't render anything.
>
> I'm writing a small patch for this.
>
> I can handle this several ways but two of them seem meaningful:
>
> 1.- Implement a custom portlet that will be rendered when the
> requested one is not available.
> This portlet will handle the situation and show a small message
> saying that the portlet is not available.
> While this is a good solution if something bad happens
> and this portlet is also not available we will se again
> the main crash of the portal.
>
> 2.- Implement a special renderer that will render the message
> directly from the container.
>
> Is there any useful solution?
>
> What do you think it's best?
In Jetspeed-2 we handle this by capturing all container invocation errors and either returning an appropriate (pluggable/configurable) error
page for non-rendering processing (Action/Event/Resource), or display an appropriate message within the PortletWindow instead.
For Pluto Portal this might require some extensive changes to do something similar, which in that case might be out-of-scope for the purpose
of Pluto Portal itself (if doable with a small fix/patch would be fine however).
Be aware that Pluto Portal is not written for nor targeted at real production usage: its primary and only purpose is to provide a testbed
environment for the Pluto Container.
If you want to expand upon the Pluto Portal yourself, you might be looking at some major rewriting to get it to acceptable quality level
(for that purpose).
If you really need a production ready Portal I suggest looking at Jetspeed-2 Portal instead.
Regards,
Ate
>
> Thank you.
>
>
>
>
>
>
>
>
>
>
>
> ____________________________________
>
>
>
>
> Gonzalo Aguilar Delgado
> Consultor CRM - Ingeniero en
> Informática
> M. +34 607814276
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>