Ian Bicking [mailto:[EMAIL PROTECTED] wrote:
> The current convention of Webware development is making it
> difficult to
> distribute or reuse servlets.
I'm thinking that rather than try to share servlets (which I would expect to
be very difficult to re-use unless the application is identical), it makes
more sense to share "components" (such as a login component or a site
navigation component) that provide some functionality and are designed to be
_used_ in servlets with a minimum of fuss. Whether those components are
mixins or simply helper classes, I'm not sure.
I may have a page that needs to display a login component, a tree navigation
component, and news of the day. I ought to be able to grab those 3
components and easily assemble them in my own servlet. I wouldn't expect to
find a reusable servlet that provides this combination.
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> So, I'm hoping people can give ideas of new things we can do with
> servlets to make this work. I think this an important
> underlying reason
> that we aren't seeing a lot of servlet-like code being shared among
> Webware users.
I'm not following your argument, maybe because I need a more concrete
example of the problem. I'm not ready to throw out inheritance or mixins
quite yet.
Obviously, in order to be re-used, your component needs to have a clean
interface without application-specific details embedded in. But I do think
that can be accomplished with mixins by requiring the user to subclass the
mixin to add in the application-specific hooks. Something like this:
class AuthenticationMixin:
# Methods to be used by servlets
def getLoggedInUser(self):
...
def writeLoginForm(self):
...
# Abstract methods must be implemented to "wire up"
# the login form with the app-specific logic
def authenticateUser(self, username, password):
raise AbstractError
# etc.
AuthenticationMixin is designed to be reusable, but it's not usable without
also wiring it in by implementing the abstract methods. That could be done
in an application-specific subclass of LoginMixin or it could be done
directly in the servlet, depending on what seems more appropriate.
- Geoff
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
