I have found a candidate solution to the problem of Turbine's session
requirements. Subclassing SessionValidator already allows for
bypassing the session redirect, but unfortunately, Turbine's doGet
method has not recorded enough information about the request to
make a choice based on the requested page.
By moving the two lines
data.setScreen ( data.getParameters().getString("screen") );
data.setAction ( data.getParameters().getString("action") );
from below the session redirect to just above the test for
"REDIRECTED_PATHINFO_NAME equals true", the screen/action names are
made available in the RunData when Turbine tests
sessionValidator.requiresNewSession(data) --- within SessionValidator,
I can test for the no-session cases by explicit name (or a naming
pattern convention) and avoid the redirect on a per-page basis.
This appears to work in all use-cases except one: If the request is
for a Flux login, Turbine correctly assigns the session, but ignores
my tr.prop "services.VelocityService.default.layout = GatewayLayout" and
substitutes a request for DefaultLayout -- all non-Flux pages behave
as expected.
Are there any other potential side-effects of moving the setAction
and setSession calls ahead of the security/session checks?
Are there any potential side-effects of leaving the session object
as null? (ie, any non-obvious service implications?)
I would expect most modern webapps will want to implement RSS-export
features and will require sessions be optional and invoked only on a
per-page or per site-area basis; there are many other scenarios where
there is no need to track session data. Some means to flip between
these modes depending on the context needs to be part of Turbine.
This method of testing the screen/action names in the SessionValidator
is not very elegant and its totally inflexible since the screen
patterns must be explicitly stated, but it does the trick (I thought
of using a pattern where no-session screens began with an underscore,
but this was only slightly less ugly than brute-force matching).
Are there any alternative ways to have the screen module determine
the result of the SessionValidator.requiresNewSession?
--
Gary Lawrence Murphy <[EMAIL PROTECTED]> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
