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.
