You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Mike Haberman <mi...@ncsa.uiuc.edu> on 2001/07/13 22:20:54 UTC
how about this for the default pipeline ?
how about something like this for the default pipeline?
-- mike
public class DefaultTurbinePipeline
implements Pipeline
{
private SessionValidator sessionValidator;
private AccessController accessController;
private Configuration;
public void init(Configuration configuration)
{
this.configuration = configuration;
// Get the instance of the Session Validator.
sessionValidator = (SessionValidator) moduleLoader.getModule(ACTIONS,
configuration.getString(ACTION_SESSION_VALIDATOR));
accessController = (AccessController) moduleLoader.getModule(ACTIONS,
configuration.getString(ACTION_ACCESS_CONTROLLER));
}
public void execute(RunData data)
{
checkLoginLogout(data);
// This is where the validation of the Session information
// is performed if the user has not logged in yet, then
// the screen is set to be Login. This also handles the
// case of not having a screen defined by also setting the
// screen to Login. If you want people to go to another
// screen other than Login, you need to change that within
// TurbineResources.properties...screen.homepage; or, you
// can specify your own SessionValidator action.
sessionValidator.execute(data);
// Put the Access Control List into the RunData object, so
// it is easily available to modules. It is also placed
// into the session for serialization. Modules can null
// out the ACL to force it to be rebuilt based on more
// information.
accessController.execute(data);
// Now these stages of execution are fixed right now, but they
// should be configurable. Each of the stages here
// should be defined in a Valve and the pipeline
// should execute each valve. Following the patterns
// in catalina there is also a ValveContext which
// can alter the execution path of the valves. What
// is listed below here could eventually be anything :-)
pipeline.preExecuteAction(data);
pipeline.executeAction(data);
pipeline.postExecuteAction(data);
pipeline.doExecute(data);
pipeline.finished(data);
// If a module has set data.acl = null, remove acl from the session.
if ( data.getACL() == null )
{
data.getSession().removeValue(AccessControlList.SESSION_KEY);
}
}
protected void checkLoginLogout(RunData data)
{
// Special case for login and logout, this must happen before the
// session validator is executed in order either to allow a user to
// even login, or to ensure that the session validator gets to
// mandate its page selection policy for non-logged in users
// after the logout has taken place.
if ( data.hasAction()
&&
data.getAction().equalsIgnoreCase(
configuration.getString(ACTION_LOGIN))
||
data.getAction().equalsIgnoreCase(
configuration.getString(ACTION_LOGOUT)))
{
// If a User is logging in, we should refresh the
// session here. Invalidating session and starting a
// new session would seem to be a good method, but I
// (JDM) could not get this to work well (it always
// required the user to login twice). Maybe related
// to JServ? If we do not clear out the session, it
// is possible a new User may accidently (if they
// login incorrectly) continue on with information
// associated with the previous User. Currently the
// only keys stored in the session are "turbine.user"
// and "turbine.acl".
if (data.getAction().equalsIgnoreCase(
configuration.getString(ACTION_LOGIN)))
{
String[] names = data.getSession().getValueNames();
if (names != null)
{
for (int i=0; i< names.length; i++)
{
data.getSession().removeValue(names[i]);
}
}
}
moduleLoader.getModule(ACTIONS, data.getAction()).execute(data);
data.setAction(null);
}
}
protected void preExecuteAction(RunData data)
throws Exception
{
TurbineTemplate.doBuildBeforeAction(data);
}
protected void executeAction(RunData data)
throws Exception
{
// If an action has been defined, execute it here. Actions
// can re-define the template definition.
if (data.hasAction())
{
Turbine.getModuleLoader().getModule(
Turbine.ACTIONS, data.getAction()).execute(data);
}
}
protected void postExecuteAction(RunData data)
throws Exception
{
TurbineTemplate.doBuildAfterAction(data);
}
//!! Get rid of hard coding.
protected void doExecute(RunData data)
throws Exception
{
// The whole pipeline starts with the target template
// specified by the 'template' paramter.
StringBuffer sb = new StringBuffer();
Resolver.parseTemplatePath(
data.getParameters().getString("template"),sb);
String target = sb.toString();
data.setTarget(target);
String targetModuleType = Turbine.getConfiguration().getString(
"pipeline.default.targetModuleType");
String module = Resolver.getModule(targetModuleType, target);
Turbine.getModuleLoader().getModule(targetModuleType, module).execute(data);
// The execution of the module that corresponds to the requested
// template may result in the target template being changed.
// This happens for example when a user isn't logged in. The
// template requested is '/Index.vm', but executing an Index
// module might result in the target template being changed
// to '/Login.vm'. We want to reset the target template value
// here in case it has changed.
target = data.getTarget();
// With this target template we start by rendering
// the appropriate layout template and everything
// goes from there.
// Need to execute the module that matches the template
// if it exists.
String layoutTemplate = Resolver.getTemplate("layouts", target);
data.getResponse().setLocale(data.getLocale());
data.getResponse().setContentType(data.getContentType());
// Now I think we have to find a page template based
// on the content type. What other criterion could
// we use. Maybe you might want to change it if
// you were branding ...
Renderer r = new Renderer();
TemplateContext context = TurbineTemplate.getTemplateContext(data);
context.put("renderer", r);
context.put("template", target);
//!! We should be able to use the renderer here, but we have
// the normalize the way it's used. right now the renderer
// is being used in templates and you specify the module type
// but when you start the pipeline you have the path to the template
// and the module type is already part of the path which
// doesn't work in the renderer. You end up with something
// like /layouts/layouts/Default.vm which obviously doesn't
// work.
//data.getOut().print(r.render("layouts", data, layoutTemplate));
data.getOut().print(TurbineTemplate.handleRequest(context, layoutTemplate));
}
protected void finished(RunData data)
throws Exception
{
TurbineTemplate.doPostBuild(data);
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: how about this for the default pipeline ?
Posted by Jason van Zyl <jv...@apache.org>.
On 7/13/01 4:20 PM, "Mike Haberman" <mi...@ncsa.uiuc.edu> wrote:
>
> how about something like this for the default pipeline?
No. Read the notes. As described in the notes what is there is
primitive and hardcoded. It basically emulates what a Page did.
Each stage or valve will be a class of it's own and you will be
able to configure a pipeline with an XML file:
<pipeline className="org.apache.turbine.pipeline.DefaultPipeline">
<valve className="org.apache.turbine.valve.Valve1"/>
<valve className="org.apache.turbine.valve.Valve2"/>
<valve className="org.apache.turbine.valve.Valve3"/>
</pipeline>
The pipeline will be constructed with the XML digester in the
commons. The valves will be added to the pipeline and they
will be executed in order. The pipeline will work this
way by the end of the weekend. Than it will be possible to
pretty much do whatever you want. Session validation and
Access control can certainly be added to the pipeline.
I'm almost done. Patience :-)
> -- mike
>
>
> public class DefaultTurbinePipeline
> implements Pipeline
> {
> private SessionValidator sessionValidator;
> private AccessController accessController;
> private Configuration;
>
> public void init(Configuration configuration)
> {
> this.configuration = configuration;
> // Get the instance of the Session Validator.
> sessionValidator = (SessionValidator) moduleLoader.getModule(ACTIONS,
> configuration.getString(ACTION_SESSION_VALIDATOR));
>
> accessController = (AccessController) moduleLoader.getModule(ACTIONS,
> configuration.getString(ACTION_ACCESS_CONTROLLER));
> }
>
> public void execute(RunData data)
> {
> checkLoginLogout(data);
>
> // This is where the validation of the Session information
> // is performed if the user has not logged in yet, then
> // the screen is set to be Login. This also handles the
> // case of not having a screen defined by also setting the
> // screen to Login. If you want people to go to another
> // screen other than Login, you need to change that within
> // TurbineResources.properties...screen.homepage; or, you
> // can specify your own SessionValidator action.
> sessionValidator.execute(data);
>
> // Put the Access Control List into the RunData object, so
> // it is easily available to modules. It is also placed
> // into the session for serialization. Modules can null
> // out the ACL to force it to be rebuilt based on more
> // information.
> accessController.execute(data);
>
> // Now these stages of execution are fixed right now, but they
> // should be configurable. Each of the stages here
> // should be defined in a Valve and the pipeline
> // should execute each valve. Following the patterns
> // in catalina there is also a ValveContext which
> // can alter the execution path of the valves. What
> // is listed below here could eventually be anything :-)
> pipeline.preExecuteAction(data);
> pipeline.executeAction(data);
> pipeline.postExecuteAction(data);
> pipeline.doExecute(data);
> pipeline.finished(data);
>
> // If a module has set data.acl = null, remove acl from the session.
> if ( data.getACL() == null )
> {
> data.getSession().removeValue(AccessControlList.SESSION_KEY);
> }
> }
>
>
>
>
> protected void checkLoginLogout(RunData data)
> {
> // Special case for login and logout, this must happen before the
> // session validator is executed in order either to allow a user to
> // even login, or to ensure that the session validator gets to
> // mandate its page selection policy for non-logged in users
> // after the logout has taken place.
> if ( data.hasAction()
> &&
> data.getAction().equalsIgnoreCase(
> configuration.getString(ACTION_LOGIN))
> ||
> data.getAction().equalsIgnoreCase(
> configuration.getString(ACTION_LOGOUT)))
> {
> // If a User is logging in, we should refresh the
> // session here. Invalidating session and starting a
> // new session would seem to be a good method, but I
> // (JDM) could not get this to work well (it always
> // required the user to login twice). Maybe related
> // to JServ? If we do not clear out the session, it
> // is possible a new User may accidently (if they
> // login incorrectly) continue on with information
> // associated with the previous User. Currently the
> // only keys stored in the session are "turbine.user"
> // and "turbine.acl".
> if (data.getAction().equalsIgnoreCase(
> configuration.getString(ACTION_LOGIN)))
> {
> String[] names = data.getSession().getValueNames();
> if (names != null)
> {
> for (int i=0; i< names.length; i++)
> {
> data.getSession().removeValue(names[i]);
> }
> }
> }
>
> moduleLoader.getModule(ACTIONS, data.getAction()).execute(data);
> data.setAction(null);
> }
> }
>
>
>
>
>
> protected void preExecuteAction(RunData data)
> throws Exception
> {
> TurbineTemplate.doBuildBeforeAction(data);
> }
>
> protected void executeAction(RunData data)
> throws Exception
> {
> // If an action has been defined, execute it here. Actions
> // can re-define the template definition.
> if (data.hasAction())
> {
> Turbine.getModuleLoader().getModule(
> Turbine.ACTIONS, data.getAction()).execute(data);
> }
> }
>
> protected void postExecuteAction(RunData data)
> throws Exception
> {
> TurbineTemplate.doBuildAfterAction(data);
> }
>
> //!! Get rid of hard coding.
> protected void doExecute(RunData data)
> throws Exception
> {
> // The whole pipeline starts with the target template
> // specified by the 'template' paramter.
> StringBuffer sb = new StringBuffer();
>
> Resolver.parseTemplatePath(
> data.getParameters().getString("template"),sb);
>
> String target = sb.toString();
> data.setTarget(target);
>
> String targetModuleType = Turbine.getConfiguration().getString(
> "pipeline.default.targetModuleType");
>
> String module = Resolver.getModule(targetModuleType, target);
> Turbine.getModuleLoader().getModule(targetModuleType,
> module).execute(data);
>
> // The execution of the module that corresponds to the requested
> // template may result in the target template being changed.
> // This happens for example when a user isn't logged in. The
> // template requested is '/Index.vm', but executing an Index
> // module might result in the target template being changed
> // to '/Login.vm'. We want to reset the target template value
> // here in case it has changed.
> target = data.getTarget();
>
> // With this target template we start by rendering
> // the appropriate layout template and everything
> // goes from there.
>
> // Need to execute the module that matches the template
> // if it exists.
> String layoutTemplate = Resolver.getTemplate("layouts", target);
>
> data.getResponse().setLocale(data.getLocale());
> data.getResponse().setContentType(data.getContentType());
>
> // Now I think we have to find a page template based
> // on the content type. What other criterion could
> // we use. Maybe you might want to change it if
> // you were branding ...
> Renderer r = new Renderer();
> TemplateContext context = TurbineTemplate.getTemplateContext(data);
> context.put("renderer", r);
> context.put("template", target);
>
> //!! We should be able to use the renderer here, but we have
> // the normalize the way it's used. right now the renderer
> // is being used in templates and you specify the module type
> // but when you start the pipeline you have the path to the template
> // and the module type is already part of the path which
> // doesn't work in the renderer. You end up with something
> // like /layouts/layouts/Default.vm which obviously doesn't
> // work.
> //data.getOut().print(r.render("layouts", data, layoutTemplate));
> data.getOut().print(TurbineTemplate.handleRequest(context,
> layoutTemplate));
> }
>
> protected void finished(RunData data)
> throws Exception
> {
> TurbineTemplate.doPostBuild(data);
> }
> }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org