Design Opinion

[James Cook <ji...@iname.com>]

I'm developing a portal application (who isn't?) that is somewhat flexible
in its design. It is driven by a servlet named Portal that makes calls to
other classes that are responsible for generating sections of HTML. Most
frameworks refer to these sections of HTML as Portlets.

I needed a container that would house these Portlets, and for various
reasons, I decided to make them servlets as well. There are quite a few
advantages to this approach:

1. Lifecycle of the servlet is managed by the servlet engine. I didn't have
to develop a container to manage access to them. If I need a portlet to be
single threaded, I can use the SingleThreadedModel interface, otherwise the
servlet manages the multithreading.

2. The main servlet can invoke them fairly easily using the
RequestDispatcher mechanism. It's working quite well.

3. I can add new portlets or remove others dynamically without affecting the
Portal servlet.

4. Each portlet has access to the user's httpsession for state information.

I haven't run across any disadvantages...this is where you come in. Am I
missing anything big here, or are there any circumstances on other servlet
engines that may affect the design?

thanks,
jim

Hiding the URI

[Pete Marsden <pk...@earthlink.net>]

How can you hide or mask the URI from the browser?  I don't want the user to
see it.

I remember seeing that you could do this with aliases using the JWS and
servlets.

Pete--

Re: Design Opinion

[Alexander Kogan <ko...@ptc.com>]

James,

Why don't you want make your portlets as regular java classes.
You may "populate" them by name using Class.forName(). Also
you may
encode class names as hidden parameters in forms.

All data can be stored in Hashtable, then pass Hashtable as
input
parameter for all classes. More over you can inherit all
portlets
from one super portlet with one "execute" method.

This design is called "Smart Servlets". You may find more
information
on Web or check some java-server books.

Of course sometimes it is not suitable.

Best,



James Cook wrote:
> 
> I'm developing a portal application (who isn't?) that is somewhat flexible
> in its design. It is driven by a servlet named Portal that makes calls to
> other classes that are responsible for generating sections of HTML. Most
> frameworks refer to these sections of HTML as Portlets.
> 
> I needed a container that would house these Portlets, and for various
> reasons, I decided to make them servlets as well. There are quite a few
> advantages to this approach:
> 
> 1. Lifecycle of the servlet is managed by the servlet engine. I didn't have
> to develop a container to manage access to them. If I need a portlet to be
> single threaded, I can use the SingleThreadedModel interface, otherwise the
> servlet manages the multithreading.
> 
> 2. The main servlet can invoke them fairly easily using the
> RequestDispatcher mechanism. It's working quite well.
> 
> 3. I can add new portlets or remove others dynamically without affecting the
> Portal servlet.
> 
> 4. Each portlet has access to the user's httpsession for state information.
> 
> I haven't run across any disadvantages...this is where you come in. Am I
> missing anything big here, or are there any circumstances on other servlet
> engines that may affect the design?
> 
> thanks,
> jim
> 
> --------------------------------------------------------------------------
> To unsubscribe, email: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commmands, email: tomcat-user-help@jakarta.apache.org

-- 
_________________________________________________________
Alexander Kogan    Parametric Technology Corporation
kogan@ptc.com      128 Technology Drive, Waltham MA 02453

Re: Design Opinion

[Eduardo Pelegri--Llopart <Ed...@eng.sun.com>]

Did you consider defining the "portlets" as custom actions?  I've seen
people doing it this way.  The main advantage is that it is relatively
intuitive to rearrange the different content within a JSP that works as
a template framework.  The custom action has access to all the data
directly, so that works pretty well.  The one issue against this
approach would be resource management; that is less well developed for
custom tags in JSP 1.1.

	- eduard/o

James Cook wrote:
> 
> I'm developing a portal application (who isn't?) that is somewhat flexible
> in its design. It is driven by a servlet named Portal that makes calls to
> other classes that are responsible for generating sections of HTML. Most
> frameworks refer to these sections of HTML as Portlets.
> 
> I needed a container that would house these Portlets, and for various
> reasons, I decided to make them servlets as well. There are quite a few
> advantages to this approach:
> 
> 1. Lifecycle of the servlet is managed by the servlet engine. I didn't have
> to develop a container to manage access to them. If I need a portlet to be
> single threaded, I can use the SingleThreadedModel interface, otherwise the
> servlet manages the multithreading.
> 
> 2. The main servlet can invoke them fairly easily using the
> RequestDispatcher mechanism. It's working quite well.
> 
> 3. I can add new portlets or remove others dynamically without affecting the
> Portal servlet.
> 
> 4. Each portlet has access to the user's httpsession for state information.
> 
> I haven't run across any disadvantages...this is where you come in. Am I
> missing anything big here, or are there any circumstances on other servlet
> engines that may affect the design?
> 
> thanks,
> jim
> 
> --------------------------------------------------------------------------
> To unsubscribe, email: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commmands, email: tomcat-user-help@jakarta.apache.org