This concept is something that I have been contemplating for sometime. I
have been recently working on a framework for Horizontal Application
Services - these application services are to Federated and Collaborative.
This framework would allow for interface based programming from the jsp
pages and within the tag handlers. By providing a centrally available
ServiceManager that is responsible for the lifecycle of each of its managed
services, the jsp and tag handler developer can request the registered
service for a particular interface. Services collaborate by having access
to the properties of one another as well as being able to register as
property change listeners of one another. Each service needs to be
configured to be run within an appropriate scope for the application. Some
services can run within application scope, some need to be at session and
still others would probably be best at request ( such as your stateManager
idea ).
One of the services I plan to implement is a PresentationService for exactly
the reasons you state - plus the ability to provide presentation related
resources such as Type Table information to fill drop down boxes, Localized
Content through logical content resolution and etc. This functionality can
be provided by collaborating with other services such as the I18N Service
for internationalization and localization and ContentDeliveryService for
logical content. This service would need to be run within the request scope
so that you don't end up with state from previous requests cluttering up the
service or the need to garbage collect it manually.
A word of caution - you need to to take care in providing any state machine
functionality within a servlet ( controlling servlet or not ) due to the
fact that there is only one servlet instance running per web app. So, you
will have multiple requests being processed by the same servlet instance -
you therefore have serious concurrency issues. It is good practice to not
have any instance variables in a servlet - especially any that need to be
updated at the session or request levels.
Any thoughts on the application services framework?
thanks,
larry
-----Original Message-----
From: Dan Cancro [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 5:42 PM
To: [EMAIL PROTECTED]
Subject: RE: What about this model?
That would work too. I made it a separate object because the concepts of
flow control and data holding seemed separable enough to me that they should
go in different classes. I can imagine a scenario where you want one kind
of flow controller, but you would want state managed in one of a few
different ways depending on the client's capacity for holding it. If I
implemented this, I would make the StateManager an instance property of the
ActionServlet.
-----Original Message-----
From: Ian.Swett [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 2:34 PM
To: [EMAIL PROTECTED]
Subject: Re: What about this model?
I don't have much experience with struts either, but what about having the
controlling servlet do the state management, rather than adding another
component to do so. The concept of a StateManager of some sort for data
storage, etc seems important.
Besides that, I really like it, but I'd like to hear what others think.
Ian Swett
