Using bits of Pluto, but no portal.

[Duncan Strang <du...@retail-j.com>]

Hi

Thanks to subscribers to this list for your answers so far.

Well it looks like we have come to the conclusion that a portal is not 
what we want.

But ... we do like the caching and life cycle management stuff in the 
portlet container (well we do today anyway).

What we actually want is the ability to create components that we can 
'plug together' in order to create dynamically configurable 
transactional web interfaces that allow us to use our extensive library 
of existing business components. Here's where the portlet container 
comes in (I think). We develop portlets that are effectively facades 
onto our existing business components, when we want to provide a feature 
to a client we simply deploy the relevant  portlet,  grab it's output 
and do stuff with it.

Have I completely lost the plot here ?
Is it a realistic proposition to use the portlet container to provide a 
fraction of it's service capabilities or is the deployment overhead too 
large ?

I'd like to know what you think.

Cheers
Duncan

Re: Using bits of Pluto, but no portal.

[Ralph Goers <Ra...@dslextreme.com>]

I heartily recommend that you look into using the Cocoon Portal for what 
you are proposing.  Although it can be a traditional portal we use it to 
create normal looking websites, primarily because it makes it easy to 
integrate various "portlets" as you are trying to do.

Duncan Strang wrote:

> Hi
>
> Thanks to subscribers to this list for your answers so far.
>
> Well it looks like we have come to the conclusion that a portal is not 
> what we want.
>
> But ... we do like the caching and life cycle management stuff in the 
> portlet container (well we do today anyway).
>
> What we actually want is the ability to create components that we can 
> 'plug together' in order to create dynamically configurable 
> transactional web interfaces that allow us to use our extensive 
> library of existing business components. Here's where the portlet 
> container comes in (I think). We develop portlets that are effectively 
> facades onto our existing business components, when we want to provide 
> a feature to a client we simply deploy the relevant  portlet,  grab 
> it's output and do stuff with it.
>
> Have I completely lost the plot here ?
> Is it a realistic proposition to use the portlet container to provide 
> a fraction of it's service capabilities or is the deployment overhead 
> too large ?
>
> I'd like to know what you think.
>
> Cheers
> Duncan
>