> I'm currently working out design details for a new project, and I've
> discovered a few constraints in Turbine that I'd like to discuss.
Ok.
> As it stands right now, the doGet method in Turbine does a lot
> of stuff, and it isn't easy to override or enhance the behavior
> (although the capability to alter the SessionValidator, login
> process, etc. is quite nice). Specifically I need to do two things
> in my application that are a bit difficult with Turbine as it stands now.
Ok.
> 1. I want to be able to do some general bookkeeping/logging for
> each request before any other processing is done.
Like what?
The reason why I say this is that you can accomplish this in your Page Module.
If you did have this functionality, what would you want passed in? Request/Response?
What
exactly would you be logging that the servlet engine can't already log for you
(JServ's debug
logging shows quite a bit of information)?
> 2. I need to do some generic initialization on each HttpSession
> object after it is created.
Again, like what? The reason why I ask is because this probably isn't a very good
design and
I want to prevent you from doing a bad design before you go down that road. :-)
HttpSession is just a hashtable. You stuff objects into that Hashtable. Those objects
may need
to have initialization on them before you stuff them into the hashtable. So, your
methodology
of stuffing those objects into the hashtable should execute the initialization.
> Of course I could extend Turbine, override doGet, copy the
> doGet code into my subclass and modify it as necessary,
> but then I wouldn't pick up changes to doGet in Turbine.
Actually, a better way would be to write a "pre-servlet" that simply wraps around the
Turbine
servlet and simply calls it by passing in the Req/Response. That way you don't have to
worry
about calling super().
> Here's what I'd like to propose:
>
> 1. Add a method called something like preHandleRequest to
> Turbine that would get called like this (code modified from
> Turbine.java):
>
> // check to make sure that we started up properly
> if (initFailureMessage != null)
> {
> throw new Exception ( initFailureMessage );
> }
>
> preHandleRequest(req, res);
>
> // get general RunData here...
>
> The default implementation of preHandleRequest wouldn't do
> anything, but a Turbine subclass could override it as desired.
-1. Next people will ask for a postHandleRequest()...also, I don't really want to
encourage
people subclassing the Turbine servlet...I don't see a reason to do that.
> Now I could override initializeSession in my subclass, call the default
> implementation, and then perform my own custom initialization.
> What does everyone think about this?
Again, I don't think this is a good idea. Prove me wrong. ;-)
> As a side question, does it make things easier for everyone if I
> submit suggestions for comment in this way, or is it easier if I
> just make my proposed changes and submit a patch for review?
> Turbine is already one of the nicest web application frameworks that
> I've seen yet, and I hope that my comments (and ultimately code
> submissions) will make it even better.
Thanks! Your submission this time was simple, so a patch wasn't needed. Especially
since this
is a design phase. I would want a patch at the end of all this once we are all in
agreement.
So, I have -1'd you above. That does not mean that the discussion is closed at all and
I'm a
bastard for not allowing this into the code. :-) You have two choices now:
#1. You need to explain good reasons for why you want to do the above. I'm VERY
hesitent to
add/modify the code in the Turbine.java class, especially if it doesn't seem entirely
necessary.
#2. Back down and do it the way that I suggested. ;-)
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]