I've been using Webware for the past 6months and have had no trouble
with many of the issues you describe below. I have gained a lot of
knowledge from the apache Turbine project, and have tried to use Webware
+ Cheetah (containment approach) in the same way as the Turbine +
Velocity approach. This has worked extremely well.
This is my basic servlet inheritance picture.
Page -> BaseApp -> SecureApp -> GenericApplications (this last one is
the one all programmers will write).
BaseApp overrides the _respond method and will define the basic flow of
all my programs (as an example, the BaseApp can do the following in
1. Session Validation
2. Program State Validation
3. Action Processing
4. Display Template
Of course BaseApp will always pass steps 1 and 2.
SecureApp is used to define a servlet which requires a login. This
servlet will just override
The Session Validation.
All my servlets which require a login will extend SecureApp and get all
the login stuff automatically. All other apps can just extend BaseApp
> The current convention of Webware development is making it
> difficult to distribute or reuse servlets.
> It's expected that many pages will not be reusable -- they'll
> be tied into their applications, calling all sorts of methods
> that are specific to that application. But most useful
> servlets have to tie into *something*, even if they could be
> reused. In the case of users, it's an issue of tying into
> the (presumably) application-specific definition of a user,
> authentication, etc. We need ways to provide
> application-specific information to potentially generic
> servlets (like a login page).
I use a config file to specify what login page/template and login logic
to use which is loaded up in SecureApp. This allows me to change the
type of login which is required, without having to rewriting any of my
servlets. All I have to do is write a new Login module which follows my
predefined API. The trick of course is coming up with a generic API.
> There is also the matter of site look. Again, many of us are
> handling our site look through inheritance -- overriding
> writeBodyParts or otherwise putting the site look in the
> SitePage. Again, the generic servlet needs some way to
> access this information.
I don't use the inheritance method here for the look. We have instead
used the Cheetah containment approach which also involves separating the
page layout from the form layout.
The layout is all controlled via a config file (i.e you can configure
the type of layout you want and also change it on the fly (but we don't
do that)) and loaded automatically by the BaseApp.
If you look at how Turbine separates their web page, I have followed
them in this department.
Look under "Module Object Encapsulation" at
My rules has been, servlets never ever deal with the layout, look of the
resulting web page. All my servlets do is create forms, processs forms,
call the appropriate business logic (which are kept in separate
modules/classes for reusability)), then set and fill up the relevant
searchlist parameters for the next screen.
> Lastly, there's the matter of specializing the generic
> servlet, which is really just another way of looking at the
> other two issues, though in this case there's the presumption
> that the servlet has a basic understanding of what to do, but
> you want to change that.
I'm not sure what you mean here ? Do you mean to dynamically change the
flow of the program using some sort of configuration (please not xml) ?
> Inheritance just doesn't work for this kind of reuse. It's
> onerous to change the inheritance structure of the generic
> servlet, because that involves editing the actual servlet
> code, making it no longer generic.
> Mixins, in my experience, can be very difficult to work with
> -- the semantics of who's method gets called where can get
> very confusing.
> It's also hard to use more than one mixin at the same time,
> they just aren't gentle with each other.
A cool idea we have played with is to create components which can be
reused in different servlets. To use them, a programmer will just need
to create an instance of this component. This component will then
automatically/dynamically attach itself to the current servlet i.e
insert it's own actions into the servlets action list, dynamically
create new action methods, add itself to the search list etc. Again, the
trick is to come up with a good api for these components. This way, we
avoid having to create mixins, or use inheritance which I agree with you
does not work very well for this purpose.
Hope I've made some sense.
My only complaint so far is not having an integrated resource loader
(think java) type module. I've had to create a module global which I
load in __init__.py. Is this the correct way of handling stuff like this