Location: syracus-stripes / Features Language: en

Features

This is a short overview of the main featured provided by the syracus-stripes framework so far.

Scriptable Actions

The main purpose of scripting is rapid developent. And also scripting in stripes breaks some if it main features i found it very usfull to have the ability to test some code before coding concrete ActionBeans.

Therefore i implemented an abstract ActionBean called BSFActionBean. If you want to use scripting facilities for your application you should follow the Best Practices from the stripes homepage and implement a BaseActionBean operating on the correct ActionBeanContext implementations for your application.

@UrlBinding( "/script.action" ) public class MyScriptActionBean extends BSFActionBean { // implement context specific stuff. }

That’s all you need to do to use your scripts.

The BSFActionBean already provides two events eval and exec. eval should be used if your scripts return a property Resolution instance. exec events only execute the given script and return to the sourcePageResolution of the request.

For example place your script hello.bsh into /WEB-INF/scripts/hello.bsh. I assume this script returns a propert ForwardResolution to a JSP page displaying a message.

import net.sourceforge.stripes.action.ForwardResolution; request.setAttribute( "Hello World" ); return( new ForwardResolution( "/hello.jsp" ) );

To call this script you just have to call ’/script.action?eval=/WEB-INF/scripts/hello.bsh.

There are some additional configuration parameters for the framework which makes the handling of the script files easy. Details may follow in near future.

Dynamic Resolution Resolving

One poor thing about stripes i really came across very often is the missing flexibility in dynamically configure the view part of an application.

And well, maybe this concept described here will break one of the main features of the stripes framework which is, being usable without external configuration.

Nevertheless, during incremental development of mid-sized to huge applications most developers come to the point when they have to reorganize their whole application layout by moving around JSP pages for example.

Stripes, at default, forces the developer to code the URLs for all Forwards and Redirects from ActionBean into the ActionBean classes themself. This is ok for small applications as it provides really fast development cycles. But in real projects it would be adviceable to be able to dynamically define views external to the ActionBean they use them. Especially when one view is used from several ActionBeans and events.

The dynamic resolution of View components in syracus-stripes uses the java resource bundles and specialized Forward- and RedirectResolution implementations. This way you are able to use ‘symbolic’ names as results from your ActionBeans and map those symbolic names in extenal resource bundles.

Use return a new ResourceBundleForwardResolution( “success” ) and map the key ‘success’ to /public/success.jsp in StripesResources.properties. Well you’re not forced to define all your mappings in StripesResources.properties. This is just a default. The ResourceBundleResolutionResolver support additional configuration parameters where you define any number of resource bundles to be used for the resolving.

Moreover this provides additional benefits when it comes to localization of your application. Instead of having to write separate code when your ActionBeans have to dispatch to different views depending on the users locale, you get this for free. Just define another mapping in a localized resource bundle and voila, users may see totally different views depending on their locale.

The last feature which come very handy on high level dynamics of your application is the feature, that all mapped resource bundle values may be dynamically created and modified.

Still remember the ’/public/sucess.jsp’ ? Well this is a really fixed definition of success in the end. How about defining one mapping for many successfull operations ?

In the resource bundle we can define the following mapping: success=/{0}/success{1}.jsp

To use this mapping properly the ForwardResolution must be initiated like new ResourceBundleForwardResolution( “success”, “public”, “Login” ); which will forward to ’/public/sucessLogin.jsp’.

and new ResourceBundleForwardResolution( “success”, “public”, “Edit” ); will forward to ’/public/successEdit.jsp’.