Java Enterprise Turbine
JET Documentation
(If you feel that the documentation is too short, please create a bug report)
^2 Action
^2.1 Old behave

^2.1.1 Defining actions

Actions must be defined in jet-config.xml like the forms. You can define actions with the JetAction tag like the following:

url="/index.jet" template="jet.ftl.pages.index"
/>

<JetAction
url="/helloworld.jet" handler="jet.examples.HelloWorldAction" transfer-encoding="gzipped"
/>

<JetAction
url="/loginform.jet" handler="jet.examples.LoginFormAction" validate="false"
/>

<JetAction
url="/loginform2.jet" handler="jet.examples.LoginFormAction2" formid="loginform"
/>

The url given is the url under which the action is reachable. If you define a template on the jetaction the template will be printed. If you need java (which will be the most case) e.g. to act on a database before printing a template you can specifiy a handler instead of a template - the handler can call different templates or delegate to a different action, so specifiying also a template will make no sense. If you specify a formid (form identifier) from a previous defined form you can easily access request parameters and validate to the form specified. If validations on the form specified and on the action the attribute validate="false" is set the form will not be validated on this action. With transfer-encoding you can specify that the content will be transferred compressed with gzip.

^2.1.2 Writing handlers
The JET Actions have to be extended by jet.servlet.JetAction or a child of it.
Given Parameters:

JetMessages messages - contains messages, specially from validations.
JetData data - contains hashmaps of the request and session data. Contains also the messages provided by the localizer files.
JetForm form - the form for the action to encode parameters - null if no form is specified in configuration.
JetContext jetContext - Context object providing all necessary objects like the HttpRequest object etc.
Example Action:
public class HelloWorldAction extends JetAction{

    public void execute( JetMessages messages, JetData data, JetForm form, JetContext jetContext ) 
	throws JetActionException, IOException{

        if(form != null){ //test2.jet called
            data.add( "newform", form.decodeForm(jetContext) );
        }else{ //test.jet called
            data.add( "newform", jetContext.getFormByUrl("/test2.jet").decodeForm(jetContext) );
        }

        render( data, "jet.ftl.pages.helloworld" );

    }


}
^2.2 New behave

^2.2.1 Defining actions

Actions must be defined in jet-config.xml like the old behave. New is that not only a Class is specified, also the method to execute:

url="/helloworld.jet" handler="jet.examples.MyAction#methodToExecute" transfer-encoding="gzipped"
/>

Same attributes like the old behave.

^2.2.2 Writing handlers
On the new behave the JET Actions have NOT to be extended by jet.servlet.JetAction or a child of it. Just define a method and specify one of the below listed parameter types as you wish/need.:
Given Parameters:

JetMessages messages - contains messages, specially from validations.
JetData data - contains hashmaps of the request and session data. Contains also the messages provided by the localizer files.
JetForm form - the form for the action to encode parameters - null if no form is specified in configuration.
JetConverer converter - holds an instance of the form - you can directly get converted field values.
JetContext jetContext - Context object providing all necessary objects like the HttpRequest object etc.
HttpServletRequest request - the servlet request object like on servlets exists HttpServletResponse reponse - the servlet response object like on servlets exists
Example Action:
public class NewBehaveAction {

    public void myexecute( JetData data, JetForm form, JetContext jetContext ) 
	throws JetActionException, IOException{

        if(form != null){ //test2.jet called
            data.add( "newform", form.decodeForm(jetContext) );
        }else{ //test.jet called
            data.add( "newform", jetContext.getFormByUrl("/test2.jet").decodeForm(jetContext) );
        }

        context.render( data, "jet.ftl.pages.helloworld" );

    }


}
NOTE: The new behave supports no special 'validate' method. Form validation is the same.
^2.3 Delegate actions
The design of JET actions allows you to delegate between the actions. For examle if you have already written an action which does already the necessary tasks, but you want to depend it on a different action. 

 ...
 delegateTo( "/otheraction.jet", jetContext, form ); 
 //--> delegates using the current form instance

 delegateTo( "/thirdaction.jet", jetContext );       
 //--> delegates fetching the request parameters in form as defined in config
^2.4 Annotations
The following annotations exists: example: 
---snip---
public class FreeformExampleAction {
    
    @OnException(method="errortest")
    @PreAction(method={"premethod"})
    @PostAction(method={"postmethod"})
    public void exampleActionMethod( 
	JetData data, JetConverter form, JetContext context
    ) throws JetActionException, IOException{
        throw new NullPointerException("123");
        //context.render(data, "jet.ftl.pages.helloworld");
    }

---snap---
Similar to the freeform actions the parameters were filled as defined - you could choose also from the same like for freeform actions. For OnException, you have to specify the exception also - if not it would not be called!

^2.4.1 Pre executed methods

You have to specify an array of method names as you can specify more than one pre action Pre methods could return a boolean if the other methods and the action should be called or not - if none returned it will be continuted as defined.
^2.4.2 Post executed methods
You have to specify an array of method names as you can specify more than one post action
^2.4.3 OnException executed methods
if this action occurs in the pre actions, on the action itself or the post actions - the defined class/method is called.