TICL is not only a set of tags generating some HTML content. It is a complete toolkit of interactive user interface WEB components that can be manipulated as any other Java bean. In a sense, it is very similar architecturally to the new Microsoft .NET platform and in some cases it offers even more flexibility and functionality. The tags themselves serve merely as a syntactic interface to the components, which encapsulate behaviour, state and user-interaction logic. State management is separated from components. You can choose to store state in rewrite URLs or in the JSP session, or even provide your own component state manager. Naturally, you can write custom component and corresponding tags and plug them in the framework.

The server-side event model in TICL encompasses what in mainstream, MVC-based JSP programming is referred to as the controller logic. Each HTTP request is transformed into a sequence of server-side events representing user actions, which are then processed by programmer defined event listeners. Even the predefined behaviour of all TICL components is implemented through default event listeners of standard TICL events. The event model is architected similarly to the Java Beans event model. However, due to the paradigm differences between conventional desktop application development and browser-based WEB development, several other abstractions such as event factories, event brokers and event dispatchers have been added in order to provide more flexibility in terms of design choices.

You can define event listeners for all TICL component related events. You can control the event engine by inserting new events in the event queue during processing and/or by cancelling the handling of current events. You can also define your own event types and have them processed by the event engine, thus plugging your business logic into the TICL event model.

As you would do in conventional desktop RAD environment, you simply place those familiar components in your JSP page by writing the corresponding tags and configuring them through tag attributes, all in a purely declarative manner. They are self-contained functional units and they behave as you would expect them to. You can nest them into one another and combine them as you wish in order to obtain a single JSP page acting as a complete program! A few quick code samples give a better pictures:

TabbedPane
Here is how you could define a tabbed pane. You can provide the content of individual tabs either inline within the body of a tabItem tag or by specifying an external file to be dynamically included:

<t:tabbedPane id="myTabs" position="top">
  <t:tabItem name="tab1" caption="First Tab" include="samplefirsttab.jsp"/>
  <t:tabItem name="tab2" caption="Second Tab">
    This is the second tab. I can place any JSP code here.
  </t:tabItem>
</t:tabbedPane>

First Tab   Second Tab

This text is from the JSP page samplefirsttab.jsp dynamically included by the TabbedPane component through the include attribute.

<t:treeView id="myTree" manageOn="client">
  <t:treeNode caption="Top Node" expanded="false">
    <t:treeNode caption="Child Node" expanded="true">
      <t:treeLeaf>First leaf</t:treeLeaf>
      <t:treeLeaf>Second leaf</t:treeLeaf>
    </t:treeNode>
    <t:treeNode caption="Another Child Node" expanded="false"/>
  </t:treeNode>
</t:treeView>

A complete framework for dealing with browser (user agent) capabilities. You can define different user agents based on name, vendor, platform and version. You can associate static or dynamic properties with user agents (of boolean, integer or string types). Dynamic browser properties, such as available plugins, screen resolution, connection speed, cookies, enabled features in a particular browser etc., are detected also. The framework is fully customizable allowing you to define your own properties, either statically in a configuration file or dynamically by providing client-side code (VBScript or JavaScript) that performs the detection. You can also customize the parsing of the HTTP user-agent header and thus handle browsers not known to TICL.

Visual appearance of GUI elements in TICL is defined through a flexible styling framework that lets you completely customize their HTML/DHTML rendering. To each GUI element, there is an associated renderer Java interface that you can implement to provide your own HTML generation. Renderers are parametrized by a set of high-level structured parameters called the skin. A renderer and a skin together make the style of a component. You can specify default styles for components, or apply different styles to individual instances of components. You can group styles into themes and apply them to whole pages. Styles and skins can also be defined inline, within a JSP page, through special purpose tags. Naturally, there is an API supporting all that and with which you can work directly.

The framework allows for a clean separation between look&feel and functional behaviour of GUI elements. No more copy&paste, no more code cluttering with tedious, browser-specific HTML details - consistency of look&feel can be easily achieved by maintaining a single TICL style sheet, a simple XML file, that is applied to all pages in your WEB application.

You can define different styles for a component based on user agent (browser). TICL will automatically select the approriate rendering based on the current user agent thus allowing you to handle browser differences with 0 code in JSP pages.

HTML forms are the cornerstone of browser-based programming. In TICL, every standard HTML form field is mapped to a server-side component and encapsulated into a custom tag providing various extensions reflecting common WEB programming practices. For instance, a label attribute lets you attach a label and position it anywhere around the form field, and a tooltip attribute lets you associate a classical tooltip to a field, appearing when the mouse goes over it. As another example, you can associated a redirect URL with individual items of a select dropdown control and server-side command handling functions (invoked through Java reflection) with buttons and form submitting links.

In addition, since every form field is a TICL component, you can process form submits by working with the TICL forms component API which provides a clean conceptual layer on top of the plain text HTTP request parameters.

TICL comes with a file upload component taking care of all multipart form processing and managing uploaded files for you.

Because form field are high-level components, you can create custom form fields by composing the standard HTML form fields into meaningful, functional units. An example of this is the DateTime TICL component that allows an end-user to enter dates in a flexible manner (e.g. through several drop down controls).

For complete code samples illustrating the form tags and API, please visit the TICL examples page (select Examples from the TICL menu).

Form validation is one of the cumbersome tasks related to WEB programming. As with any other error checking and reporting, it is something programmers tend to avoid and postpone until it becomes absolutely necessary.

TICL comes with a form validation mechanism that allows you to concisely and easily specify the conditions under which a given form field or a group of inter-dependent fields is valid, all in purely declarative contextual way. A set of special purpose tags lets you declare validation rules and instruct TICL to evaluate them either at the server, once the form has been submitted, or at the browser before the form is submitted, or even while the end-user is typing her input! The validation rules are extremely general and flexible - they allow you to define dependencies between form field values by specifying things like "apply this validation rule when the value of that field is A and the value of that other field is not empty", for example.

Error reporting is done in a similar fashion, namely by declaring rules triggered by TICL when a given field or form becomes invalid or in general when a validation error of a certain type occurs. A form is never processed, i.e. button command handlers are not invoked and a form submit event is not generated, whenever there is an invalid field in the form. All this allows to completely isolate form validation from the form specification and from the form processing.

For examples and to see the validation mechanism in action, please go to the TICL examples page (select Examples (from) the TICL menu).

The Data Objects framework and related tags allows you to work with arbitrary data structures (e.g. Java Beans, SQL records, EJBs) in a transperant manner in your JSP pages. The data object related tags let you manipulate structured fields, both nested and indexed, by providing a clean scoping mechanism as well as an extended syntax for accessing fields of arbitrary types anywhere in a data structure.

Data Objects can be associated with TICL forms where data fields are automatically mapped to/from form fields. This is similar to other frameworks with funcionality that allows you to populate an HTML from a Java bean and then populate the bean from the form submit values. However, TICL has several notable advantages:

• TICL comes with a customizable typing framework where form fields, being typed server-side component, can be mapped to arbitrary Java types. Common type conversions come predefined with TICL, but you can customize them and add new ones.
• Data Objects in TICL are based on a generic framework that can work not only with Java beans, but with arbitrary structured data, as long as a few interfaces are implemented.
• The association even goes as far as to allow you to link GUI commands (like buttons, menu items and links) to data object (bean) methods!

Like most Java web programming frameworks, TICL is based on the concept of a controller. However, it does not force you to use a single controller servlet. You can just develop individual pages based on it and use it in an existing project. The API also lets you integrate with Model 2 or virtually any other web framework that you might have adopted. For example, TICL comes with an integration module for the popular Struts framework. Using that module, you can use the powerful TICL forms as a replacement of Struts forms in addition to the other web components found only in TICL.