> > The reason why I say this is that you can accomplish this in your Page
> Module.
>
> Yes, I think that will work for my application.
good!
> That could work too, but I wouldn't want to marry myself to a specific
> servlet engine, and yes, Request/Response would get passed in.
right...i wouldn't want to marry you to the engine either. jserv is a horrible
wife...:-)
> True, but it would still be convenient to perform the object initialization
> and hashtable stuffing in one place for the objects that are required for
> each session.
Uh...that is simple to do in your applications:
public static void sessionInit(HttpSession sess, String name, Object my obj)
{
obj.init();
sess.put (name,obj);
}
> The main thing I'm trying to accomplish is to attach a "workspace" object to
> my session as soon as it is created. This is both a data staging area and
> an interface layer to other middle-tier and back-end services, such as our
> EJB server. The reason I'm localizing this stuff in a workspace object is
> because it will also be used for non-web (i.e. Java) clients.
Uh. This is what the User object is for. You should use the User.addTemp(). You
shouldn't put
stuff directly in the Session when you are using Turbine. By using the User object to
do it,
you can easily do something like the above code to wrap around things with your own
User
object implementation.
> If you're still opposed to the idea of adding the initializeSession method
> then I think I can accomplish what I need by writing a simple service for
> accessing my workspace that will retrieve the object from the session,
> creating it first if it doesn't already exist, but see below for additional
> comments.
See above.
> Yes, that's a nice generic way to take care of any pre-processing
> requirements.
Yep.
> Well, that doesn't seem like a bad idea to me, although I don't have a need
> for it myself.
The point is that it isn't needed. I want to give an API that is restrictive enough to
help
encourage good design. :-) This is kinda what Webmacro is all about.
> So, it appears that I can do what I need to do without touching the Turbine
> class. However I'm not quite ready to give up on the idea in principle yet.
> As I've been learning Turbine, I've found that the mechanisms for extending
> it are fairly obvious and convenient, which is a primary characteristic of a
> quality framework. I brought up these two cases because the mechanism for
> extending Turbine the way that I wanted wasn't obvious to me, and I'm not
> sure that the solutions we're batting around would work well in all cases.
thanks.
> I would think that others besides myself would run into the same questions
> I've brought up here, so shy not create an obvious (i.e. self documenting)
> solution in the framework?
I would rather just create useful documentation for turbine that is kinda a "use
cases"...with
Turbine, I'm trying to semi-revolutionize the way that people were doing servlets
before into
a really good framework. So far, you think it is a good framework. that means that you
"get
it". :-)
> If you want to disourage people from subclassing Turbine, another option
> would be to create default objects like RequestPreProcessor,
> SessionInitializer, etc. that get called from Turbine in the appropriate
> places.
> A user could then tell Turbine to use alternate implementations
> (subclasses) of these objects in the Turbine properties file. Actually I
> guess they would simply be new types of Actions. This would make the
> implementation of these features more consistent with the rest of the
> framework (SessionValidatior, AccessController, etc.)
Again, I don't want to clutter up the primary servlet more than it needs to be. Having
all
this "ifdef" code in the servlet would be a mess. I don't like it. It just isn't
needed. For
example, other people may want to be able to pass in things other than
Request/Response to
their requestpreprocessor. Putting that into an API would just limit them to much.
-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]
