RE: Embedding the portlet container into existing software

[Nick Lothian <ni...@essential.com.au>]

Comments inline. You may want to discuss this further on the pluto-dev list,
since most of this is to do with embedding Pluto, not using it as-is.

> 
> 
> Hello together,
> 
> Since quite some time now I am getting into Portal and Portlet
> development. I am trying to extend an existing "portal" software
> to handle JSR168 Portlets also and am trying to do so using the Pluto 
> container. I have investigated the Pluto portal driver and 
> tried around 
> a bit.
> 
> It was a bit hard to learn from that portal implementation 
> because it is 
>    using factories and intefaces a lot, thus often the inner workings 
> are not obvious at 1st sight, so I wished that the example 
> portal is a 
> bit simpler and not so "academic", cos otherwise I could have taken a 
> look into Jetspeed2, exo, Cocoon etc. (although having done 
> so also) :-)
> 
> Okay, this is not ment to be destructive critique cos I am 
> thankful for 
> what the Pluto team has done! However, perhaps in future the 
> driver is a 
> bit downgraded for purposes of reference.
> 

Yes, this is a common complaint. We (mostly David) are attempting to addess
these problems by simplifying things in the pluto 1.1 stream. You may want
to investigate that.


> So, my question is if anyone has yet tried to implement/integrate the 
> Pluto PortletContainer into his/her custom software or has tried to 
> implement a portal on his/her own. Looking at the Pluto Portal Driver 
> Servlet, it seems that any fragments (portlet, page etc.) are 
> rendered 
> into the HttpServletResponse "directly". However, I would 
> like to "pull" 
> portlet fragments from within existing JSP pages, e.g. using 
> (custom?) 
> taglibs / ELs or so, just like for example <c:import /> does for any 
> markup resource.
> 
> Is there any way to invoke a portlet rendering from the main 
> JSP portal 
> page? This is because I forward to a JSP in the end of my Servlet 
> doGet()/doPost() methods where all other stuff is already done so far 
> and I would hate to reimplement the entire core, I already downgraded 
> from Struts to a single custom Servlet already. :-)
> 

Theoretically it certainly is possible. However portlets aren't really
intended to be used within a conventional, existing web application. 

I believe that the Jetspeed project has a sub project called "portlet
bridges" which lets you embed conventional JSP applications inside a JSR-168
portlet. That might be a better approach than having a part Servlet, part
Portlet application.

There are also various extensions/wrappers for Struts to let you use it in a
Portlet environment.

> Sorry for this long writing, but I would be very glad if 
> someone could 
> point me a direction, cos from googling the web and reading much 
> documents and a book on portal/portlet development, it was 
> too hard to 
> find info for the portal implementor's view, not the portlet 
> developer.
> 

Jetspeed 2, Coccon and uPortal are all open source and embed Pluto (see
http://portals.apache.org/pluto/powered_by_pluto.html). Browsing the source
is of them is probably the best information you can get.


> If the answer is a RTFM (xyz), it is just fine because I may 
> have missed 
> something despite of it :-) Thank you!
> 

\

Good luck! 

Nick

Re: Embedding the portlet container into existing software

[Timo -Blazko- Boewing <li...@neveprise.net>]

Hello Nick,

Thanks for your quick and detailed reply.

Nick Lothian wrote:
[...]
> 
> Yes, this is a common complaint. We (mostly David) are attempting to addess
> these problems by simplifying things in the pluto 1.1 stream. You may want
> to investigate that.
> 

Yes, I will do so and I am looking forward in downloading the next 
release when it is out (or subversion yet, I will see if time permits; 
btw. can I fetch using normal cvs client?).

[... about integration into existing MVC pattern project]
> 
> Theoretically it certainly is possible. However portlets aren't really
> intended to be used within a conventional, existing web application. 
> 
> I believe that the Jetspeed project has a sub project called "portlet
> bridges" which lets you embed conventional JSP applications inside a JSR-168
> portlet. That might be a better approach than having a part Servlet, part
> Portlet application.

Hello no :-) Having read a lot and also from experience, it is quite 
hard to integrate non-portlet apps as portlets. Also, this is not really 
my goal because I just have a "framework" yet but no apps, they are 
still about to be implemented as portlets from scratch, luckily :-)

> 
> There are also various extensions/wrappers for Struts to let you use it in a
> Portlet environment.

The decision to downgrade my current app from Struts to a common servlet 
was not so bad because it is just kind of portal and there is no much 
feature growth to be expected, because the rest will be done by 
"external" portlet apps (e.g. admin stuff etc.).

> 
> 
> Jetspeed 2, Coccon and uPortal are all open source and embed Pluto (see
> http://portals.apache.org/pluto/powered_by_pluto.html). Browsing the source
> is of them is probably the best information you can get.
> 

Okay, think I will wait a bit and see next Pluto release but will also 
consider to have a second look into current Jetspeed 2 and Cocoon releases.
The main problem I focus is to integrate Puto PortletContainer into my 
servlet in that kind that I might "pull" my prepared portlet contents 
from my "master" JSP instead of concatenating the entire response fomr 
the servlet side (you know, from a developer point of view, because I 
know that JSPs are becoming normal Java printlns and that later).
I do not hav that large dependenciees yet that a reconstruction is 
impossible, but I like the idea of integrating Pluto using EL/Taglibs 
plus the rest in the servlet.
The point is that currently the portal layout (still table rows and 
cells....) are prepared from my stuff as plain structured Beans/POJOs 
and that my main JSP is iterating that layout info, so a call to 
something like <my:callPortletFragment id="app2" /> would be great 
instead of doing the fragment concatenation directly in 
HttpServletResponse or so like shown in the Pluto driver.

> 
> Good luck! 
> 
> Nick
> 

Thank you really much for your time and assistance, I will place a note 
if I male significant progress, because it may also relevant to toher 
developers and users. If well-elaborated, I surely can provide code 
samples or so, if interested.


-- 
greetings,                   |  /"\
                              |  \ /  ASCII-Ribbon-Campaign
Timo                         |   X     Against HTML Mail
                              |  / \

Re: Embedding the portlet container into existing software

[Timo -Blazko- Boewing <li...@neveprise.net>]

Hello Nick,

Thanks for your quick and detailed reply.

Nick Lothian wrote:
[...]
> 
> Yes, this is a common complaint. We (mostly David) are attempting to addess
> these problems by simplifying things in the pluto 1.1 stream. You may want
> to investigate that.
> 

Yes, I will do so and I am looking forward in downloading the next 
release when it is out (or subversion yet, I will see if time permits; 
btw. can I fetch using normal cvs client?).

[... about integration into existing MVC pattern project]
> 
> Theoretically it certainly is possible. However portlets aren't really
> intended to be used within a conventional, existing web application. 
> 
> I believe that the Jetspeed project has a sub project called "portlet
> bridges" which lets you embed conventional JSP applications inside a JSR-168
> portlet. That might be a better approach than having a part Servlet, part
> Portlet application.

Hello no :-) Having read a lot and also from experience, it is quite 
hard to integrate non-portlet apps as portlets. Also, this is not really 
my goal because I just have a "framework" yet but no apps, they are 
still about to be implemented as portlets from scratch, luckily :-)

> 
> There are also various extensions/wrappers for Struts to let you use it in a
> Portlet environment.

The decision to downgrade my current app from Struts to a common servlet 
was not so bad because it is just kind of portal and there is no much 
feature growth to be expected, because the rest will be done by 
"external" portlet apps (e.g. admin stuff etc.).

> 
> 
> Jetspeed 2, Coccon and uPortal are all open source and embed Pluto (see
> http://portals.apache.org/pluto/powered_by_pluto.html). Browsing the source
> is of them is probably the best information you can get.
> 

Okay, think I will wait a bit and see next Pluto release but will also 
consider to have a second look into current Jetspeed 2 and Cocoon releases.
The main problem I focus is to integrate Puto PortletContainer into my 
servlet in that kind that I might "pull" my prepared portlet contents 
from my "master" JSP instead of concatenating the entire response fomr 
the servlet side (you know, from a developer point of view, because I 
know that JSPs are becoming normal Java printlns and that later).
I do not hav that large dependenciees yet that a reconstruction is 
impossible, but I like the idea of integrating Pluto using EL/Taglibs 
plus the rest in the servlet.
The point is that currently the portal layout (still table rows and 
cells....) are prepared from my stuff as plain structured Beans/POJOs 
and that my main JSP is iterating that layout info, so a call to 
something like <my:callPortletFragment id="app2" /> would be great 
instead of doing the fragment concatenation directly in 
HttpServletResponse or so like shown in the Pluto driver.

> 
> Good luck! 
> 
> Nick
> 

Thank you really much for your time and assistance, I will place a note 
if I male significant progress, because it may also relevant to toher 
developers and users. If well-elaborated, I surely can provide code 
samples or so, if interested.


-- 
greetings,                   |  /"\
                              |  \ /  ASCII-Ribbon-Campaign
Timo                         |   X     Against HTML Mail
                              |  / \