<t:fckeditor.editor t:id="biography"
t:value="celebrity.biography"
t:toolbarSet="Simple" t:width="300" t:height="150"/>

Well, I have to admit that to get the component properly positioned in Internet Explorer 7, I had to use some additional markup, to place the FCKEditor component and its label inside a simple table, like this:

<t:parameter name="biography">
   <table cellpadding="0" cellspacing="0">
   <tr>
   <td valign="top"> <t:label for="biography"/></td>
  <td> <t:fckeditor.editor t:id="biography" t:value="celebrity.biography" t:toolbarSet="Medium" t:width="350" t:height="200"/></td>
</tr>
</table>
</t:parameter>

After the text of the biography is entered, formatted and submitted, what gets sent to the server (and is stored in a property of the page class) is a piece of HTML with all the markup that is needed to reproduce the formatting. We can later display the biography on the details page, but right now we need to make sure that the new information (and a new Celebrity object containing it) is stored properly in the data source.

All we need to do for this is to add the following fragment of code to the AddCelebrity page:
@ApplicationState
private IDataSource dataSource;
Object onSubmitFromCelebrity()
{
  dataSource.addCelebrity(celebrity);
  return ShowAll.class;
}

We are handling form submission here, so our event handler handles the submit event and is named appropriately, according to convention. Looks all right, doesn't it? This will work for now, but in the next chapter, we'll find out that in such a situation we should handle the "success" event. So the method should be better named onSuccessFromCelebrity.

We have added an event handler and a reference to the data source ASO. When the form with the new celebrity is submitted, we store the resulting Celebrity object using the data source existing for this purpose and display the ShowAll page.
However, at the moment the table that displays our collection has two extra columns, for biography, and birthDateVerified properties. We do not want to see them, so let's modify the ShowAll page template:

<t:grid t:source="celebritySource" rowsPerPage="5" row="celebrity"
remove="id, biography, birthDateVerified" reorder="lastName,firstName,occupation,dateOfBirth">

Finally, to get the biography displayed at the Details page, let's make the necessary preparations. All we need to do is to add the following piece of markup to the
page template:

<tr>
  <td>Occupation:</td>
  <td>${celebrity.occupation}</td>
</tr>
<tr>
  <td valign="top">Biography:</td>
<td>
  <t:outputraw t:value="celebrity.biography"/> </td>
</tr>

Now add a new celebrity and a brief biography for him or her as I did above for John Lennon. Format the biography using different styles and colors to your heart's content and then click on the Save button. You will see the ShowAll page and the newly added celebrity will be somewhere at the end of collection, perhaps on page four. Find the new celebrity and click on the last name to see the details. Depending on how you formatted the biography, you should see something similar to this:

As you can see, all the formatting is displayed properly, and this is the reason why we used a new component, OutputRaw in the last example. In fact, this component is quite similar to an ordinary Output component, or even to a basic extension—it simply outputs whatever is given to it as a value. The difference is that both regular output and extension encode the content that they insert into the page while OutputRaw just inserts into the resulting HTML its value, no matter what it contains.
For instance, if the value provided by the component's binding is <b>bold text</b>, then regular output will encode angle brackets and produce the following result: &lt;b&gt;bold text&lt;/b&gt;. As a result, instead of formatted text, the page will display the tags verbatim: <b> bold text</b>. The OutputRaw however will insert into the page what was given to it, and as a result, we'll see bold text.

Security Note: Please use the OutputRaw component with caution. If you will use it to freely display any content entered by a random user, someone might enter a hostile script and achieve sinister results that you cannot even imagine.

Summary

• We have learned to use four powerful and useful components—Grid, BeanEditForm, DateField and FCKEditor. They can save us a lot of work since with minimal con figuration, they produce a rather sophisticated, functionally rich piece of interface. We have also found out that:
• We can change the way an object is displayed by Grid and BeanEditForm components, in terms of which properties are displayed and how they are ordered.
• We can override the default rendering of a property by Grid or the default editor selected for it by BeanEditForm, using the <t:parameter> element.
• We can modify the titles of the columns in the Grid or the labels of the fields in the BeanEditForm by providing appropriate messages in the application's message catalog.

We can change the appearance of the components by overriding the default CSS styles in the stylesheet that we provide ourselves. We already have several controls that accept user input in the application, but nowhere have we checked what kind of input is submitted so far. This is acceptable at the initial stage of development, when we are the only users of the application, and we know for sure which kind of information should be entered in each field. However, every real life application must validate user input, and if there are errors, it should inform the user about them in a friendly and clear way. The next chapter will discuss the powerful validation system of Tapestry 5.

Page 6 Of 6 - Advanced Components from the book "Tapestry 5 - Building Web Applications"

Your Name / Email Address
Comment
Spam Protection - Please enter the code in the image -

Listen to code