http://book.mentaframework.org/recentTopics/list.page JForum - http://www.jforum.net have got problem with activating my account. I received email but when I click on the link it was not working, is this link is correct? [url=http://book.mentaframework.org/?81ac61f9145e]http://book.mentaframework.org/?81ac61f9145e[/url], ]]> http://book.mentaframework.org/posts/preList/41/44.page http://book.mentaframework.org/posts/preList/41/44.page GMT http://book.mentaframework.org/posts/preList/38/41.page http://book.mentaframework.org/posts/preList/38/41.page GMT http://book.mentaframework.org/posts/preList/37/39.page http://book.mentaframework.org/posts/preList/37/39.page GMT http://book.mentaframework.org/posts/preList/36/38.page http://book.mentaframework.org/posts/preList/36/38.page GMT

NEW HAVEN, Conn. -- Yale football coach Tom Williams resigned Wednesday amid a probe by the university into whether he lied on his resume about being a candidate for a prestigious Rhodes scholarship, the New Haven Register reported.
Williams said last month that when he was a senior linebacker at Stanford in 1992 he was a candidate for a Rhodes scholarship, but passed up the opportunity in favor of an NFL tryout.
He spoke on the issue while Yale quarterback Patrick Witt, a Rhodes finalist, debated whether to play in the season finale against archrival Harvard or miss the game for an interview that would determine if he obtained the scholarship.

Witt opted to play in the Nov. 19 game, which Yale lost 45-7.
Williams, who turns 42 Thursday, listed on his resume submitted to Yale that he had been a Rhodes finalist.
The university launched an inquiry after The New York Times reported that the Rhodes Trust, which finances the scholarship, had no record of Williams ever applying for the scholarship.
The result of the inquiry has not been made public. Williams, in a statement announcing his decision, sought to explain the discrepancy.




]]> http://book.mentaframework.org/posts/preList/35/37.page http://book.mentaframework.org/posts/preList/35/37.page GMT
Chatsworth Sierra Canyon (14-0), in just its third season of 11-man football, was selected to represent the South after routing Lancaster Paraclete 47-14 in the Southern Section East Valley Division finals. The Trailblazers average 46.1 points per game and are led by 1,000-yard rushers Xavier Menifield and Danny Jordan and quarterback Tyler Stewart, who has thrown for 2,245 yards and 32 touchdowns.

Le Grand, from a town of 1,650 people southeast of Merced, has had a football team since the 1920s and this year's edition might be the school's best ever--even better than last year's team which won the program's first section title.

The Sac-Joaquin Section champion Bulldogs are averaging a whopping 58.5 points per game and are led by Daniel Guizar, who has rushed for almost 2,000 yards and 35 touchdowns. Quarterback Alex Bucio has thrown for 2,344 yards and 490 touchdowns.

The Division IV game will be followed by the Division I showdown between Santa Margarita (12-2) and Bellarmine Prep of San Jose (12-1).

Stay logged in for live scoring updates from both games.

-- Steve Galluzzo]]> http://book.mentaframework.org/posts/preList/34/36.page http://book.mentaframework.org/posts/preList/34/36.page GMT http://book.mentaframework.org/posts/preList/29/30.page http://book.mentaframework.org/posts/preList/29/30.page GMT [code]
public class MyAction implements Validatable {

public String execute() {

// your action stuff here...

}

public void prepareValidator(Validator val, String innerAction) {

Rule required = new RequiredRule();

val.add("username", required, "required_error");
val.add("username", new StringRule(6, 30), "invalid_username");

val.add("age", required, "required_error");
val.add("age", new IntegerRule(18, 50), "invalid_age");

val.add("password", required, "required_error");
val.add("password", new StringRule(4, 20), "invalid_password_length");
val.add("password", new EqualRule("password", "passconf"), "password_does_not_match");

val.add("passconf", required, "required_error");

}
}
[/code]
The code above is perfectly correct and legal, but we are creating too many new objects on each request without a real need for it. A rule is thread-safe by design and you should re-use the same instance across different requests. A possible fix for this problem is illustrated in the code below:
[code]
public class MyAction implements Validatable {

private static final Rule requiredRule = new RequiredRule();
private static final Rule stringRule1 = new StringRule(6, 30);
private static final Rule integerRule1 = new IntegerRule(18, 50);
private static final Rule stringRule2 = new StringRule(4, 20);
private static final Rule equalRule1 = new EqualRule("password", "passconf");

public String execute() {

// your action stuff here...

}

public void prepareValidator(Validator val, String innerAction) {

val.add("username", requiredRule, "required_error");
val.add("username", stringRule1, "invalid_username");

val.add("age", requiredRule, "required_error");
val.add("age", integerRule1, "invalid_age");

val.add("password", requiredRule, "required_error");
val.add("password", stringRule2, "invalid_password_length");
val.add("password", equalRule1, "password_does_not_match");

val.add("passconf", requiredRule, "required_error");

}
}
[/code]
However note that it is not very easy to read the validation code when the rules are defined outside the [i]prepareValidator()[/i] method. A better approach is to make the rule constructor private and create a static [i]getInstance()[/i] method that will return instances of the rule and it will be smart enough to return the same instance when the same object is requested. Check below how we would accomplish this with the [i]NegativeRule [/i]introduced in the previous chapter.
[code]
import java.util.HashMap;
import java.util.Map;


public class NegativeRule extends BasicRule {

private final int min;
private final Map<String, String> tokens = new HashMap<String, String>();

private static final Map<Integer, Rule> cache = new HashMap<Integer, Rule>();
private static final Rule RULE = new NegativeRule();

private NegativeRule() {
this.min = Integer.MIN_VALUE;
this.tokens.put("min", String.valueOf(min));
}

private NegativeRule(int min) {
this.min = min;
this.tokens.put("min", String.valueOf(min));
}

public static Rule getInstance() {
return RULE;
}

public synchronized static Rule getInstance(int min) {
Rule rule = cache.get(min);

if (rule == null) {
rule = new NegativeRule(min);
cache.put(min, rule);
}

return rule;
}

public boolean check(String value) {

try {

int x = Integer.parseInt(value);

return x < 0 && x >= min;

} catch(Exception e) {

return false;
}
}

public Map<String, String> getTokens() {
return tokens;
}
}
[/code]
Check how we are using a cache to return the same instance for each "min" parameter passed to the [i]getInstance()[/i] method. This will avoid creating unnecessary duplicates of the same object.

Most of the provided rules inside the [i]org.mentawai.rule[/i] package implement the [i]getInstance()[/i] method. So when using them you should make use of this method to obtain instances of the rule. Check the example below:
[code]
public class MyAction implements Validatable {

public String execute() {

// your action stuff here...

}

public void prepareValidator(Validator val, String innerAction) {

Rule required = RequiredRule.getInstance();

val.add("username", required, "required_error");
val.add("username", StringRule.getInstance(6, 30), "invalid_username");

val.add("age", required, "required_error");
val.add("age", IntegerRule.getInstance(18, 50), "invalid_age");

val.add("password", required, "required_error");
val.add("password", StringRule.getInstance(4, 20), "invalid_password_length");
val.add("password", EqualRule.getInstance("password", "passconf"), "password_does_not_match");

val.add("passconf", required, "required_error");

}
}
[/code]
When coding your own rules, you should provide a [i]getInstance()[/i] method whenever possible. But this is not really a necessity. It is just a good practice that it is worth mentioning for the competent programmer.
]]> http://book.mentaframework.org/posts/preList/28/29.page http://book.mentaframework.org/posts/preList/28/29.page GMT [code]
import java.util.HashMap;
import java.util.Map;


public class NegativeRule extends BasicRule {

public NegativeRule() { }

public boolean check(String value) {

try {

int x = Integer.parseInt(value);

return x < 0;

} catch(Exception e) {

return false;
}
}

public Map<String, String> getTokens() {
return null; // no tokens...
}

}
[/code]
When you extend [i]BasicRule [/i]you should implement two methods: check() and getTokens().

:arrow: check(String value): In this method you receive the value you are suppose to validate and just do it, however you want to, returning true or false.

:arrow: getTokens(): In this method you return a map with tokens and their values to be used by error messages. The default implementation in BasicRule is to return null, so you should only implement this method if you have tokens to return.

A token is used inside error messages so that it can be substituted for values associated with the rule. For example, in our simple rule above, the negative number has no minimum boundary. Let's change it to include a possible minimum:
[code]
import java.util.HashMap;
import java.util.Map;


public class NegativeRule extends BasicRule {

private final int min;
private final Map<String, String> tokens = new HashMap<String, String>();

public NegativeRule() {
this.min = Integer.MIN_VALUE;
this.tokens.put("min", String.valueOf(min));
}

public NegativeRule(int min) {
this.min = min;
this.tokens.put("min", String.valueOf(min));
}

public boolean check(String value) {

try {

int x = Integer.parseInt(value);

return x < 0 && x >= min;

} catch(Exception e) {

return false;
}
}

public Map<String, String> getTokens() {
return tokens;
}
}
[/code]
Note that now we have the possibility to validate the input value based on a minimum number and we are returning the token "min" with whatever value is given to that minimum number. Therefore you may have an error message like the one below:
[code]
invalid_number = Your negative number should be bigger than %min%.
[/code]
The %min% token is substituted with the value returned in the [i]getTokens() [/i]method. The [i]IntegerRule [/i]that comes with Mentawai also returns tokens for its min and max values. The tokens of a rule are nothing more than its properties that you may want to display along with the error messages.

There are other types of validation that are not solely based in the value itself. For example you may want to perform validation based on the user locale and you may want to perform validation of one field based on another field.

The most common example of a validation that depends on the locale is date validation. Depending on the user locale the date 12/30/2008 may be valid or not. Below is the source code of a simple rule to validate dates. Note that we are now extending [i]LocaleRule [/i]instead of [i]BasicRule[/i].
[code]
import java.util.*;
import java.text.*;

public class DateRule extends LocaleRule {

private static final int STYLE = DateFormat.SHORT;

public DateRule() {

}

public boolean check(String value, Locale locale) {

DateFormat df = DateFormat.getDateInstance(style, locale);

df.setLenient(false);

try {

df.parse(value);

return true;

} catch(ParseException e) {

return false;

}
}

public Map<String, String> getTokens() {

return null;
}

}
[/code]
Note that now the [i]check()[/i] method receives not just the value but also the locale of the user performing the request. You should use the locale in any way you want to perform the validation. Mentawai already comes with a complete [i]DateRule [/i]so you should not need to code a rule for dates. This was just an example for you to understand how the [i]LocaleRule [/i]works in case you want to write your own.

The last form of common validation is when you need to compare two fields to determine whether one field is valid or not. If you thought about password and password confirmation you were right. For that we can extend the [i]CrossRule [/i]class. Check the source below for a simple [i]EqualRule [/i]that validates whether two fields have the same value:
[code]
import java.util.HashMap;
import java.util.Map;

public class EqualRule extends CrossRule {

private final String[] fields;

public EqualRule(String field1, String field2) {
this.fields = new String[] { field1, field2 };
}

protected String[] getFieldsToValidate() {
return fields;
}

public boolean check(String[] values) {

return values[0].equals(values[1]);
}

public Map<String, String> getTokens() {
return null;
}
}
[/code]
When inheriting from [i]CrossRule [/i]you should implement two abstract methods:

:arrow: getFieldsToValidate() should return an array of the field names that will be compared.

:arrow: check(String[] values) receives the values of the fields indicated by the[i] getFieldsToValidate()[/i] method, so that you can perform any comparison you want to validate them.

Note that Mentawai gets the field values for you from the action input and pass them along with the check method so that you can compare them and return the validation result. Mentawai already comes with a complete [i]EqualRule [/i] in the [i]org.mentawai.rule[/i] package.

Another very useful built-in rule that you can use for your advantage is the [i]RegexRule[/i]. Check below how a [i]SocialSecurityNumberRule [/i]could be implemented by inheriting from [i]RegexRule[/i]:
[code]
public class SSNRule extends RegexRule {

/** The regex to use for SSN validation. */
public static final String PATTERN = "^\\d\\d\\d\\-\\d\\d\\-\\d\\d\\d\\d$";

public SSNRule() {
super(PATTERN);
}
}
[/code]
You could have also used the [i]RegexRule [/i]with the Social Security Number pattern without the need to create a new rule for it. See below:
[code]
Rule rule = new RegexRule("^\\d\\d\\d\\-\\d\\d\\-\\d\\d\\d\\d$");
[/code]
As you can see, by inheriting from [i]BasicRule[/i], [i]LocaleRule[/i], [i]CrossRule [/i]and [i]RegexRule [/i]you can perform any kind of validation for your action input values.

]]> http://book.mentaframework.org/posts/preList/27/28.page http://book.mentaframework.org/posts/preList/27/28.page GMT
To code your validation filter, you should inherit from [i]org.mentawai.filter.ValidationFilter[/i] and implement the abstract method [i]prepareValidator()[/i]. Check the example below:
[code]

public class HelloValidator extends ValidationFilter {

public void prepareValidator(Validator val, Action action, String innerAction) {

Rule required = RequiredRule.getInstance();

val.add("username", required, "required_error");
val.add("username", StringRule.getInstance(6, 30), "invalid_username");

val.add("age", required, "required_error");
val.add("age", IntegerRule.getInstance(18, 50), "invalid_age");

val.add("password", required, "required_error");
val.add("password", StringRule.getInstance(4, 20), "invalid_password_length");
val.add("password", EqualRule.getInstance("password", "passconf"), "password_does_not_match");

val.add("passconf", required, "required_error");
}
}
[/code]
The method [i]prepareValidator()[/i] is very similar to the same method of the [i]Validatable[/i] interface, the only difference being that it also passes as a parameter the action object that the filter is being applied to. The rest is the same. You can use an i18n file or you can place the error messages in the filter code, pretty much like you can do when using the [i]Validatable [/i]interface. One thing to note is that if you use an i18n file, the name of the file will be /validation/[i]filtername[/i]_[i]localehere[/i].i18n. So for the filter above it would be /validation/HelloValidator_pt.i18n, /validation/HelloValidator_en.i18n, etc.

Then you can apply the filter to one or more actions inside the application manager. Below is an example:
[code]
@Override
public void loadActions() {

action(HelloAction.class)
.filter(new HelloValidator());

// OR

ActionConfig ac = new ActionConfig(HelloAction.class);
ac.addFilter(new HelloValidator());
addActionConfig(ac);
}
[/code]
]]> http://book.mentaframework.org/posts/preList/26/27.page http://book.mentaframework.org/posts/preList/26/27.page GMT [code]
public class MyAction extends BaseAction implements Validatable {

public String execute() {

// your action stuff here...

}

public void prepareValidator(Validator val, String innerAction) {

if (isPost()) {

Rule required = RequiredFieldRule.getInstance();

val.add("username", required, FIELD_REQUIRED_ERROR);
val.add("username", StringRule.getInstance(6, 30), INVALID_USERNAME_LENGTH);

val.add("age", required, FIELD_REQUIRED_ERROR);
val.add("age", IntegerRule.getInstance(18, 50), INVALID_AGE);

val.add("password", required, FIELD_REQUIRED_ERROR);
val.add("password", StringRule.getInstance(4, 20), INVALID_PASSWORD_LENGTH);
val.add("password", EqualRule.getInstance("password", "passconf"), PASSWORD_DOES_NOT_MATCH);

val.add("passconf", required, FIELD_REQUIRED_ERROR);
}
}

private static final String FIELD_REQUIRED_ERROR = "Field required!";
private static final String INVALID_USERNAME_LENGTH = "Username length invalid!";
private static final String INVALID_AGE = "Invalid age!";
private static final String INVALID_PASSWORD_LENGTH = "Invalide password length!";
private static final String PASSWORD_DOES_NOT_MATCH = "Passwords do not match!";
}
[/code]
In the example above, only a POST request will be validated. A GET will not have any validation. You can also perform validation based on the inner action, which is very common as each inner action will have its own validation. Check below:
[code]public class MyAction extends BaseAction implements Validatable {

public String execute() {

// your action stuff here...

}

public void prepareValidator(Validator val, String innerAction) {

if (innerAction != null && innerAction.equals("addUser")) {

Rule required = RequiredRule.getInstance();

val.add("username", required, FIELD_REQUIRED_ERROR);
val.add("username", StringRule.getInstance(6, 30), INVALID_USERNAME_LENGTH);

val.add("age", required, FIELD_REQUIRED_ERROR);
val.add("age", IntegerRule.getInstance(18, 50), INVALID_AGE);

val.add("password", required, FIELD_REQUIRED_ERROR);
val.add("password", StringRule.getInstance(4, 20), INVALID_PASSWORD_LENGTH);
val.add("password", EqualRule.getInstance("password", "passconf"), PASSWORD_DOES_NOT_MATCH);

val.add("passconf", required, FIELD_REQUIRED_ERROR);
}
}

private static final String FIELD_REQUIRED_ERROR = "Field required!";
private static final String INVALID_USERNAME_LENGTH = "Username length invalid!";
private static final String INVALID_AGE = "Invalid age!";
private static final String INVALID_PASSWORD_LENGTH = "Invalide password length!";
private static final String PASSWORD_DOES_NOT_MATCH = "Passwords do not match!";
}
[/code]
In the code above, only the "addUser" innerAction will be validated. All others, including the default (no inner action) [i]execute()[/i] method will not be validated. Recall that [i]innerAction == null[/i] means the [i]execute()[/i] method was called.

Because of the dynamic characteristic of the validation, you should avoid creating new rule objects on each request. That's why we have been using the [i]getInstance()[/i] method instead of the [i]new [/i]constructor for our rules. The [i]getInstance()[/i] method returns the same instance every time, avoiding the creation of new objects on every request. Despite the fact that the Java garbage collector is very powerful nowadays, you should try to avoid creating too many Java objects unnecessarily.

Most of the Mentawai built-in rules already provide the [i]getInstance()[/i] method. If possible, and as a good practice, you should provide this method with any new rule you code. We will see how to create new validation rules in a bit.]]> http://book.mentaframework.org/posts/preList/25/26.page http://book.mentaframework.org/posts/preList/25/26.page GMT
If Mentawai does not find the i18n file or the key inside the i18n file, it will just display the key as the error message. So just place your error message as the key and you are ready to go. See the example below:
[code]
public class MyAction implements Validatable {

public String execute() throws Exception {

// your action stuff here...

}

public void prepareValidator(Validator val, String innerAction) {

Rule required = RequiredRule.getInstance();

val.add("username", required, FIELD_REQUIRED_ERROR);
val.add("username", StringRule.getInstance(6, 30), INVALID_USERNAME_LENGTH);

val.add("age", required, FIELD_REQUIRED_ERROR);
val.add("age", IntegerRule.getInstance(18, 50), INVALID_AGE);

val.add("password", required, FIELD_REQUIRED_ERROR);
val.add("password", StringRule.getInstance(4, 20), INVALID_PASSWORD_LENGTH);
val.add("password", EqualRule.getInstance("password", "passconf"),
PASSWORD_DOES_NOT_MATCH);

val.add("passconf", required, FIELD_REQUIRED_ERROR);

}

private static final String FIELD_REQUIRED_ERROR = "Field required!";
private static final String INVALID_USERNAME_LENGTH = "Username length invalid!";
private static final String INVALID_AGE = "Invalid age!";
private static final String INVALID_PASSWORD_LENGTH = "Invalide password length!";
private static final String PASSWORD_DOES_NOT_MATCH = "Passwords do not match!";
}
[/code]
Note that we are just using the error message as the key. Mentawai executes the following logic to find the error message.

:arrow: Look for the i18n file. If you don't find the i18n file, use the key as the error message.
:arrow: If you found the i18n file, look for the key. If you don't find the key, use the key as the error message.
:arrow: If you found the key, print the associated text as the error message.

As you can see, it is very easy to place your error messages inside your source code instead of using an i18n file.]]> http://book.mentaframework.org/posts/preList/24/25.page http://book.mentaframework.org/posts/preList/24/25.page GMT [code]
filter(new ValidatorFilter());

// or

addGlobalFilter(new ValidatorFilter());
[/code]
Below is an example of how to validate your action using the [i]Validatable [/i]interface. Note that you are not using annotation or xml. You are using [b]programmatic configuration[/b] to setup the validation of your form fields.
[code]
public class MyAction implements Validatable {

public String execute() {

// your action stuff here...

}

public void prepareValidator(Validator val, String innerAction) {

Rule required = RequiredRule.getInstance();

val.add("username", required, "required_error");
val.add("username", StringRule.getInstance(6, 30), "invalid_username");

val.add("age", required, "required_error");
val.add("age", IntegerRule.getInstance(18, 50), "invalid_age");

val.add("password", required, "required_error");
val.add("password", StringRule.getInstance(4, 20), "invalid_password_length");
val.add("password", EqualRule.getInstance("password", "passconf"), "password_does_not_match");

val.add("passconf", required, "required_error");

}
}

[/code]
To each form field is applied a set of validation [i]rules[/i]. For example, for the field "age" we are applying two rules:

:arrow: [i]RequiredRule[/i]: enforces that a field is present, in other words, not blank or null
:arrow: [i]IntegerRule[/i]: enforces that a field is an Integer between a min and a max value

Mentawai validation rules are as flexible as Java code because they are Java code, not XML or Annotation. If you check the [i]javadoc [/i]of the [i]IntegerRule [/i]class you will find out that it has three different constructors:

:arrow: [i]IntegerRule()[/i]: meaning any integer will be accepted, even negative integers
:arrow: [i]IntegerRule(int min)[/i]: meaning any integer >= min will be accepted
:arrow: [i]IntegerRule(int min, int max)[/i]: meaning any integer >= min and <= max will be accepted

Mentawai comes with many read-to-use rules in the package [i]org.mentawai.rule[/i] like [i]StringRule[/i], [i]NumberRule[/i], [i]EmailRule[/i], [i]FileRule[/i], etc. Plus it comes with a very handy rule called [i]RegexRule [/i]which allows you to validate any field based on a regular expression. You will not be surprised to find out that many other Mentawai rules (like the [i]EmailRule[/i]) inherit from [i]RegexRule [/i]to do its job. As we will see later in this chapter, it is very, very easy to create your own rules for validation as well in case the provided ones do not suit your needs.

If a validation rule fails, a error message associated with it is displayed to the user. Because these messages are usually internationalized (translated into many languages) and more strongly because you don't want to mix content with source code, they should reside in a text file we call i18n file. (Soon you will see how to bypass this good practice and place your error messages together with your code if you prefer to)

The default location for your validation error messages are /validation/[i]actionamehere[/i]_[i]localehere[/i].i18n. However if you prefer to keep all your messages in a single file (that we call master) you can invoke the following method inside your application manager:
[code]
LocaleManager.useMasterI18N(true);
[/code]
If you do this, all your messages, not just for validation but all internationalized messages in your application will be stored in the file /i18n/master_[i]localehere[/i].i18n.

So for example if your are NOT using the master file, your action is [i]MyAction [/i](like our example above) and you have two languages pt and en, you would have the following files: /validation/MyAction_pt.i18n and /validation/MyAction_en.i18n.

But if you are using the master file, then all your messages from all your actions would be stored in the files: /i18n/master_pt.i18n and /i18n/master_en.i18n.

Some people will prefer to store all text messages in a single file what makes things easier when it comes the time to translate everything to a new language. Other people will prefer to have a separate file for each action. It is up to you what approach to take.

An example of the validation messages for the action above is listed below:
[code]
###############################################
# Validation messages for MyAction
###############################################

required_error = Required field cannot be left blank
invalid_username = Your username must be between %min% and %max% characters long.
invalid_age = You must be %min% years old or older.
invalid_password_length = Your password must be between %min% and %max% characters long.
password_does_not_match = Passwords do not match.
[/code]
Note how we are using the tokens %min% and %max% to place some validation information inside our error messages. You should already be familiar with the i18n file syntax because it is the same of the Java [i]Properties [/i]class.

Now to display these messages inside a JSP page, all you have to do is make use of some very useful mentawai tags. See our example below:
[code]
<%@ taglib uri="/WEB-INF/lib/mentawai.jar" prefix="mtw" %>

<html>
<body>
<h1>Hello Validation!</h1>

<mtw:form>

Your username: <mtw:input name="username" size="25" />

<mtw:outError field="username">
<mtw:out />
</mtw:outError>


Your age: <mtw:select name="age" size="1" list="ages">

<mtw:outError field="age">
<mtw:out />
</mtw:outError>


Your password: <mtw:input type="password" name="password" size="25" />

<mtw:outError field="password" >
<mtw:out />
</mtw:outError>


Again please: <mtw:input type="password" name="passconf" size="25" />

<mtw:outError field="passconf">
<mtw:out />
</mtw:outError>

<mtw:submit value="Enviar" action="HelloWorld.mtw" method="post" />

</mtw:form>
</body>
</html>
[/code]
Note that this tags are conditional tags, in other words, nothing inside the tag will be shown if there is no error for the field. If you want to display all field errors in the top of your page instead of near each field in your form, you can use another menta tag, the <mtw:outFieldErrors> tag.
[code]
<!-- List all field errors -->
<mtw:outFieldErrors>
<h4>Here are the error messages:</h4>
<mtw:loop>
<mtw:out />

</mtw:loop>
</mtw:outFieldErrors>
[/code]
To conclude, an important tip that we will see later in the book: Use the Mentawai HTML form tags <mtw:input>, <mtw:select>, <mtw:checkboxes>, etc. so you don't have to worry about re-displaying the values that the user typed in case of validation error. We know you don't want to place a bunch of scriptlets in your JSPs to do this. ;-)
]]> http://book.mentaframework.org/posts/preList/23/24.page http://book.mentaframework.org/posts/preList/23/24.page GMT
You also saw the main consequences of any web application: Forward and Redirect. You were also introduced to the Chain, Stream and Ajax consequences.

Now it is time to dive into the many Mentawai features. Remember that one of the goals of the Mentawai framework is to abstract all the repetitive tasks of any web project. Stuff like Validation, Authentication, Form Handling, Sending Email, etc. are boring and repetitive, so the framework has to offer you a very simple and intuitive way of dealing with that. With Mentawai you should never waste time re-inventing the wheel. It tries to do all the boring work for you so you can have fun getting your project done and making your boss happy.]]> http://book.mentaframework.org/posts/preList/21/22.page http://book.mentaframework.org/posts/preList/21/22.page GMT
The basic and most common consequence you will use in your web projects is the [b]Forward[/b]. In Mentawai, this is the [i]org.mentawai.core.Forward[/i] class, which implements the [i]org.mentawai.core.Consequence[/i] interface. The interesting aspects about a forward are listed below:

:arrow: A forward always happens in the server-side, in other words, the client (the browser) does not realize that a forward is happening. For example, if you make a call to the action http://www.mysite.com/Hello.mtw and the result of the action [i]Hello.class[/i] is a forward to /hello.jsp, [b]the location in the address bar of your browser will not change[/b] to /hello.jsp. That's because the forward is really happening on the server-side. No other request is needed from the browser. The request is passed over to the JSP page and the result is returned in the same request that asked for the [i]Hello [/i]action. This is exactly the opposite of what happens when you do a Redirect.

:arrow: A forward will always pass the action and all its contexts ([i]Input[/i], [i]Output[/i], [i]Session[/i], [i]Cookies[/i], etc.) to the JSP page. When you do a forward, the results of the action execution are made available to the JSP page. This is the opposite of what happens when you do a Redirect. When you do a redirect, a new request is done by the browser to a new action or JSP page. All the previous action information before the redirect is discarded.

The classic scenario is:

WebRequest ---------> Action generates some results ----------> Forward to JSP to display the results

For example for the simple action below you can configure some forwards:

[code]
public class HelloAction extends BaseAction {

public String sayHi() {

output.setValue("message", "Hi there!");

return SUCCESS;
}

public String sayHello() {

output.setValue("message", "Hello there!");

return SUCCESS;
}
}
[/code]

Inside the application manager:

[code]

public void loadAction() {

action(HelloAction.class)
.on(SUCCESS, "sayHi", new Forward("/hi.jsp"))
.on(SUCCESS, "sayHello", fwd("/hello.jsp"));

// OR

ActionConfig ac = new ActionConfig(HelloAction.class);
ac.addConsequence(SUCCESS, "sayHi", new Forward("/hi.jsp"));
ac.addConsequence(SUCCESS, "sayHello", fwd("hello.jsp"));
addActionConfig(ac);

}
[/code]

Just keep in mind that whenever you want the [b]action information to be displayed in the JSP page[/b] you will most likely want a [b]Forward[/b] consequence. Another point to keep in mind is that if the user hits the [i]Reload [/i]button in the browser, the whole action is executed again.


[color=blue][size=18][b]Redirecting to a new URL[/b][/size][/color]

In Mentawai, the Redirect consequence is implemented by the core class [i]org.mentawai.core.Redirect[/i], which implements the core interface [i]org.mentawai.core.Consequence[/i]. When you issue a Redirect consequence, you are really telling the browser: "[i]Hey! Please do another web request to the this URL here![/i]". As a result, the URL location in the address bar of the browser will change to the redirect URL and all the information about the action that performed the redirect will be discarded.

Contrary to the Forward, a Redirect happens in the client-side, in other words, it is the browser that performs another web request to the JSP page or action. You could use a redirect, for example, when you want to avoid having the user accidentally hitting the [i]reload [/i]button and executing the action again.

There are many ways to a redirect in Mentawai. Below I will explain each one:

:arrow: [b][color=blue]Regular redirect[/color][/b]

This is the redirect you will be using 99% of the time and it is [b]always related to the [i]context path [/i]of your web application[/b]. The [i]context path[/i] is the directory where your application is located inside the Tomcat [i]webapps [/i]directory. It is what allows the same Tomcat to run a bunch of different web applications together and independently.

Below are some examples:
[code]
on(SUCCESS, redir("/congrats.jsp"));

addConsequence(JSP, new Redirect("/user/users.jsp"));
[/code]
The first redirect will tell the browser to perform another web request to the following URL:

http://www.mysite.com/DVDStore/congrats.jsp

The second redirect will tell the browser to perform another web request to the following URL:

http://www.mysite.com/DVDStore/user/users.jsp

This is assuming that your context path is "DVDStore". If your context path was the [i]ROOT context path[/i], which is the [i]ROOT [/i]directory inside the Tomcat [i]webapps [/i]directory, your redirect URLs would be:

http://www.mysite.com/congrats.jsp

http://www.mysite.com/user/users.jsp


:arrow: [b][color=blue]Redirect relative to the web server[/color][/b]

You can use this redirect when you want to perform a redirect [b]to another web application running in the same web server[/b]. For example:
[code]
on(SUCESS, redir("//BookStore/showBooks.mtw"));

on(JSP, redir("//index.jsp"));
[/code]
When you start the redirect with a double slash ("//"), you are just saying: "Hey, I don't want to be relative to the context path!" Therefore, even if you context path is "DVDStore", the resulting redirect URLs for the examples above will be:

http://www.mysite.com/BookStore/showBooks.mtw

http://www.mysite.com/index.jsp

This type of redirect is rare. It is only needed when you are running two different applications in the same servlet container that are somehow related to each other.


:arrow: [b][color=blue]Redirect with dynamic parameters[/color][/b]

Sometimes you want to perform a redirect, but you will only know the parameters of the URL at runtime. For example, you want to redirect the browser to the action that shows all the books for a certain category. This could be something like:

http://www.mysite.com/BookStore/Book.show.mtw?cat=<CATEGORY_ID>

To setup this redirect with a dynamic parameter, you can do this:
[code]
.on(SUCCESS, redir("/Book.show.mtw", true));
[/code]
The true above indicates that this is a redirect with dynamic parameters that will come from the action output. So our action will just do something like this:
[code]
public class BookAction extends BaseAction {

public String add() {

// add a new book to the database somehow...

output.setValue("cat", book.getCategory());

return SUCCESS;
}
}
[/code]
Assuming that book.getCategory() returns 43, the resulting URL would be:

http://www.mysite.com/BookStore/Bood.show.mtw?cat=43

Note that all the values from the action output will be added as parameters to the redirect URL.


:arrow: [b][color=blue]Redirect to a dynamic URL[/color][/b]

Sometimes you will not even know the URL you want to redirect to. This is rare, but can happen, for example, when you want to redirect your user to a URL saved in a database. Here is how it works:
[code]
on(SUCCESS, redir());

on(JSP, new Redirect());
[/code]
When you create a redirect using the constructor with empty parameters (or make use of the helper method redir() with empty parameters), the redirect will expect the URL to come from the action output. Here is an example of an action:
[code]
public class BookmarkAction extends BaseAction {

public String go() {

// get the URL from the database

String url = "http://www.mentaframework.org";

output.setValue(Redirect.REDIRURL_PARAM, url);
}
}
[/code]
Note that you are using the REDIRURL_PARAM from the Redirect consequence to place the dynamic URL inside the action output. You may have other values inside the action output and that's how the redirect class knows how to find the dynamic URL.


Last but not least about the Redirect consequence:

:arrow: If you redirect contains the string "://" inside it, it is assumed that you want to do a redirect to a absolute address. Examples:
[code]
on(SUCCESS, redir("http://www.cnn.com"));

on(FTP, redir("https://www.safe.com"));
[/code]
The redirect understands that the above redirect are all absolute URLs, not relative to anything.

:arrow: There are no redirects relative to the request

This is on purpose. If you try to do something like [i]on(SUCCESS, redir("[b]loosepage.jsp[/b]"))[/i], Mentawai will automatically assume that you meant [i]on(SUCCESS, redir("[b]/loosepage.jsp[/b]"))[/i]. Redirects relative to the request are not needed and only introduce confusion.

:arrow: You can also use a dynamic URL with dynamic parameters. Below is how to configure this redirect in the application manager:
[code]
on(SUCCESS, redir(true));

on(SUCCESS, new Redirect(true));
[/code]
:arrow: Dynamic parameters will be automatically encoded. Dynamic URLs will not be encoded, in other words, if they have any hardcoded parameter it is assumed that it is already encoded.


[color=blue][size=18][b]Chaining actions[/b][/size][/color]

For a single web request you can chain different actions in the server-side before invoking a consequence that will return a result to the browser. For example you can have a request handled by action A chained to action B chained to action C and then action C returns a result that will invoke a consequence. You should note that like a forward, chaining actions happens in the server-side. Below is an example of how to configure a chain consequence:
[code]
@Override
public void loadActions() {

ActionConfig helloAction = new ActionConfig(HelloAction.class, "hello");
ac2.addConsequence(SUCCESS, new Forward("/show.jsp"));
addActionConfig(helloAction);

ActionConfig ac = new ActionConfig(HiAction.class, "hi");
ac.addConsequence(SUCCESS, new Chain(helloAction));
addActionConfig(ac);
}
[/code]
Or you can use the less verbose style:
[code]
@Override
public void loadActions() {

ActionConfig helloAction = action(HelloAction.class, "hello")
.on(SUCCESS, fwd("/show.jsp"));

action(HiAction.class, "hi")
on(SUCCESS, chain(helloAction));
}
[/code]
Before you configure any chain consequence, you must understand that [b]action chaining is rare and in most cases there is no need for you to make use of it[/b]. Let's take a classic example where you have an action that adds an user and another action that lists all the users. You may get tempted to do a chain like:
[code]
ActionConfig showAction = action(User.class, "show")
.on(SUCESS, fwd("/show.jsp"));

action(User.class, "add")
.on(SHOW, chain(showAction))
.on(ERROR, fwd("/addUser.jsp"));
[/code]
Although definitely not a sin, this could have been done much better with a redirect consequence:
[code]
action(User.class, "show")
.on(SUCESS, fwd("/show.jsp"));

action(User.class, "add")
.on(SHOW, redir("/User.show.mtw", true) // true = dynamic parameters
.on(ERROR, fwd("/addUser.jsp"));
[/code]
So now after the [i]add[/i] inner action is done, it will redirect (not chain) to the show inner action. If the user hits the reload button, only the show inner action will be executed again, and not the whole chain. Note that we are supporting dynamic parameters for the redirect, that's because we may need to add some parameters to the URL before redirecting, for example:

http://www.mysite.com/User.add.mtw?category=34

As we saw in the previous chapter about redirect, these parameters will come from the action output.

To conclude, here is what you should keep in mind when using a chain consequence:

:arrow: Think if you don't really want a redirect to an action instead of a chain. The question you should ask yourself is: [i]Do you want to execute everything again if the user press the reload button?[/i]

:arrow: When two actions are chained, the input and output of the first are passed to the second.

:arrow: Each action will be executed with its own set of filters. If we have a global filter, then it will be executed twice, one time for each action.

:arrow: You can also pass an inner action to the chain controller:
[code]
ac.addConsequence(SHOW, new Chain(helloAction, "hello"));

on(SHOW, chain(helloAction, "hello"));
[/code]

[color=blue][size=18][b]Other consequences[/b][/size][/color]

Mentawai comes with other consequences and you can also code your own consequences. For example, to return an image or a binary file you can use the [i]StreamConsequence[/i]:

In the action:
[code]
public class ImageAction extends BaseAction {

public String execute() {

byte[] image = getImageBytesSomehow();

output.setValue(StreamConsequence.STREAM_KEY, image);
output.setValue(StreamConsequence.CONTENT_LENGTH_KEY, image.length);

return SUCCESS;
}
}
[/code]
In the [i]ApplicationManager[/i]:
[code]
public void loadActions() {

action(ImageAction.class)
.on(SUCCESS, stream("image/jpg"));

// or

ActionConfig ac = new ActionConfig(ImageAction.class);
ac.addConsequence(SUCCESS, new StreamConsequence("image/jpg"));
addActionConfig(ac);
}
[/code]
You can place a byte array or a [i]InputStream [/i]as the stream key in the action output. If for example the file is a PDF, you don't want to load everything in memory in a byte array:
[code]
public class PDFAction extends BaseAction {

public String execute() {

FileInputStream fis = new FileInputStream("review.pdf");

output.setValue(StreamConsequence.STREAM_KEY, fis);
output.setValue(StreamConsequence.FILENAME_KEY, "review.pdf");
// InpuStream has no size...

return SUCCESS;
}
}
[/code]
An in the ApplicationManager:
[code]
public void loadActions() {

action(PDFAction.class)
.on(SUCCESS, stream("application/pdf"));

// or

ActionConfig ac = new ActionConfig(PDFAction.class);
ac.addConsequence(SUCCESS, new StreamConsequence("application/pdf"));
addActionConfig(ac);
}
[/code]
For Ajax, you can use the [i]AjaxConsequence [/i]that uses a renderer to format the action response into an ajax response (JSON, XML, etc.)

Action:
[code]
public class TestAction extends BaseAction {

public String autoCompleter() {

String sourceInput = input.getStringValue("sourceInput");

Map<Integer, String> map = new LinkedHashMap<Integer, String>();

if(sourceInput.startsWith("a")) {

map.put(1, "a. Somebody with id 1");
map.put(2, "a. Somebody with id 2");
map.put(3, "a. Somebody with id 3");

} else if(sourceInput.startsWith("b")) {

map.put(4, "b. Somebody with id 4");
map.put(5, "b. Somebody with id 5");
map.put(6, "b. Somebody with id 6");

} else {

map.put(7, "*. Somebody with id 7");
map.put(8, "*. Somebody with id 8");
map.put(9, "*. Somebody with id 9");
}

output.setValue(AjaxConsequence.KEY, map);

return SUCCESS;
}

}
[/code]
ApplicationManager:
[code]
public void loadActions() {

action(TestAction.class, "autoCompleter")
.on(SUCCESS, new AjaxConsequence(new JSONGenericRenderer()));

// or

action(TestAction.class, "autoCompleter")
.on(SUCCESS, ajax(new JSONGenericRenderer()));

}
[/code]]]> http://book.mentaframework.org/posts/preList/20/21.page http://book.mentaframework.org/posts/preList/20/21.page GMT