A situation just came up where the need for an object to have a lifespan longer than a model but shorter than a session arose.
E.g. right now if you place something in context in a model, it's there until the user logs out or the session ends, unless you take it out again. If you want something to last the lifetime of a sequence (or a workflow), there's no "place" to put it.
Doing a req.setParameter(name, value) from within a model simply discards the value when the next model's execution begins - this is a candidate for the "place" to hold such values. (Alternately, parameters should/could be made read-only when a model's execution begins, so at least you know this *isn't* possible - right now it just silently drops the ball, which is a bug I suppose). In an apparent conflict, a "Command" object *can* pass a new parameter to a new model. This is inconsistent.
This is the scenario: A model executes, and gets a value (say a company number) from the db. The next model in sequence needs this company number - how does the first model "tell" the second one about the value, other than via Context, or by triggering the next model via a Command?
Does anyone have a strong view as to how this should happen? I know SequenceContext exists, but it's specific to sequences, and not generic enough to also be used in Workflows (isn't it?) My vote would be for "per request" context to be the request parameters (and attributes), and for these to "survive" into the next model unless they are specifically overridden by the sequence (or workflow) by configuration.
Cheers,
Michael Nash
JGlobal Ltd. http://www.jglobal.com
Bahamas Commerce and Trade http://www.bahamascommerce.com
How about setting the value in the Request or Response object?
Regards, Steve
-- Java/J2EE Developer/Integrator Co-Chair, Dallas/FortWorth J2EE Sig 214-724-7741
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
