What you should know:

• Metadata for scaffoling your GUI (described here).

What you need to compile/run the examples:

• java1.5 or newer
• opensource framework: agimatec-validation : download agimatec-validation.jar
• optional: javax.servlet.jar (servlet-api)
• optional: opensource frameworks/tools: agimatec-tools : download annomark-dist.zip and annogen.jar

1. Create model classes

We start with a plain java class, our model, used to transport attributes from the server to the GUI. (You can use DWR for marshaling object instances between Java and JavaScript/JDOM).

Example class “Business”:

import javax.persistence.*;

public class Business {
@Id
@Column(name=”business_id”, nullable=false, unique=true)
Long businessId;
@Column(name=”name”, nullable=false, unique=true, length=200)
String name;
@Column(name=”active”, nullable=false)
boolean active;
// getters, setters follow…
}

2. Write or generate xml meta data

You can write the xml meta data manually, or – if your classes have javax.persistence.* annotations – you can generate them using agimatec-tools/annomark.jar (described here):

<bean id=”com.agimatec.Business” impl=”com.agimatec.Business”>
<feature key=”mainKey”>
<value class=”string”>businessId</value>
</feature>
<property name=”businessId”>
<feature key=”uniqueKey”>
<value class=”boolean”>true</value>
</feature>
</property>
<property name=”name” mandatory=”true” maxLength=”200″>
<feature key=”uniqueKey”>
<value class=”boolean”>true</value>
</feature>
</property>
<property name=”active” mandatory=”true”/>
</bean>

Store the file as “beaninfos-default.xml” in the classpath.

2. Access the MetaBean

This requires agimatec-validation.jar to compile:

import com.agimatec.validation.MetaBeanManagerFactory;
import com.agimatec.validation.model.MetaBean;

MetaBeanManagerFactory.getRegistry().
addResourceLoader(“beaninfos-default.xml”);

MetaBean metabean = MetaBeanManagerFactory.getFinder().findForClass(Business.class);

3. Generate JSon for metabean(s)

We want to use the meta data in the AJAX layer, to have information about the properties, their types and additional features (mandatory, max-length, …) as a JSON formatted string. agimatec-validation offers a JSONGenerator, based on a freemarker template:

import com.agimatec.validation.json.JSONGenerator;

JSONGenerator generator = new JSONGenerator();
String json = generator.toJSON(metabean);
System.out.println(json);

This prints this JSON string:

agimatec.namespace(“agimatec.metadata”);

(function(){

var metaBean0 = {
“id” : “com.agimatec.Business”,
“beanClass” : “com.agimatec.Business”,
“name” : “Business”,
“features” :{   “mainKey” : “businessId”},
“properties” :{
“active”:{
“name” : “active”,
“type” : “boolean”,
“features” : {       “mandatory” : true       }},
“businessId”:{
“name” : “businessId”,
“type” : “long”,
“features” : {       “uniqueKey” : true       }},
“name”:{
“name” : “name”,
“type” : “java.lang.String”,
“features” : {       “maxLen” : 200,       “mandatory” : true,       “uniqueKey” : true       }},
“version”:{
“name” : “version”,
“type” : “int”,
“features” : {       }}}};

agimatec.metadata.metaBeans = {“com.agimatec.Business” : metaBean0};})();

4. Write a servlet to deliver JSON for the AJAX GUI

The java code for the servlet should not be a surprise, for it consists of what we have seen so far:

public void init() throws ServletException {
super.init();
MetaBeanManagerFactory.getRegistry().addResourceLoader(“beaninfos-default.xml”);
}

public void service(HttpServletRequest servletRequest, HttpServletResponse res)
throws ServletException, IOException {
Map<String, MetaBean> metaBeans = MetaBeanManagerFactory.getFinder().findAll();
// output JSON:
res.setContentType(“text/javascript”);
PrintWriter writer = res.getWriter();
String json = new JSONGenerator().toJSON(metaBeans.values());
writer.write(json);
}

Thats basically all! With this infrastructure your AJAX GUIs have access to meta information about the model classes.

5. Enrich meta data with information for the GUI-layer

You can enrich the xml meta data with additional hints (field sequence, formats, …) – whatever your GUI needs. If hhe additional information cannot be generated automatically, you should keep them in a separate xml-file:

<bean id=”com.agimatec.Business”>
<feature key=”DESCRIPTION”>
<value class=”string”>{name}</value>
</feature>
<feature key=”SORTING”>
<value class=”list”>
<string>name</string>
<string>active</string>
</value>
</feature>
<!–Visualisation as table–>
<feature key=”TABLE_COLUMNS”>
<value class=”list”>
<string>name</string>
<string>active</string>
</value>
</feature>
</bean>

Save this as “beaninfos-gui.xml ” in the classpath and register the file in the init() method of the servlet, too:

MetaBeanManagerFactory.getRegistry().addResourceLoader(“beaninfos-gui.xml”);

You see, that the JSON code will contain the additional information as well, because the MetaBeanManager merges them.

So far, we have the infrastructure to support meta data that allows us to build generic AJAX GUIs. The JSON string can be cached, because it will never change while the application is running.

6. User-specific meta data

We can go one step further: We can also support user-specific meta data! A usual requirement in a web application is, that – depending on the role of a user that is logged in – field-level permissions must be supported:
User A is allowed to change the “active”-state of our “Business” entity, while User B has read-only access to the field and the field is hidden for User C, …

This could also be useful, when a user can customize its GUI (disable fields) by himself or when the application is used by different companies with different settings for their users….

How does it work? – Use additional xml files and merge them in the JSON servlet. (You can also generate the meta beans during runtime programmatically).

beaninfos-role1.xml:

<bean id=”com.agimatec.Business”>
<property name=”active”>
<feature key=”readonly”>
<value class=”boolean”>true</value>
</feature>
</property>
</bean>

Extension of the servlet:

String customInfos = “beaninfos-role1.xml”; // determine this from session or request dynamically!
XMLMetaBeanInfos xmlInfos =
new XMLMetaBeanURLLoader(getClass().getResource(customInfos)).load();
Map<String, MetaBean> metaBeans =
MetaBeanManagerFactory.getEnricher().enrichCopies(xmlInfos);

The statements after “// output JSON” stay the same (see previous code fragment).

More information?

We already got some more posts in German about metadata and code generation, explaining the concepts and giving examples:

• TransferObjects generieren
• agimatec-tools als OpenSource auf google.code released!
• Statt Modellieren: Annotieren und generieren
• Klassen mit Mehrwert: Validierung und Metadaten

The open-source frameworks have a WIKI and additional examples or junit testcases, that help you.

If you have questions, do not hesitate to contact us!

This is the fifth article in our mini-series about developing highly ajaxified portlets. Other articles are:

• Generate Your UI Using Metadata
• Inter Portlet Communication
• Using YUI loader for your own javascript modules
• Portlet namespaces and javascript

In theory.

In practice, you will be faced with a problem that is obviously a blind spot of the portlet definition (at least, the “old” JSR-186): how to communicate between portlets. The ability to mix-and-match portlets is key to a truly pluggable application formed of portlets.

To solve the communication problem, we have developed a solution much like the one developed by the folks at liferay, but a bit more tuned and optimized for a fully pluggable solution.

Portlet Services and Invokers

Our implementation follows a simple pattern: Portlets are able to promote services to a page-central instance and can include interaction elements that are used to invoke services that match certain criteria:

• the type of object the service must be able to handle
• the type of operation the service offers

Promoting a service to other portlets includes:

• specifying what type of operation (CREATE/READ/UPDATE/DELETE) is offered
• a text telling the user what happens when invoking the service
• the function that should get called on service activation

Using these simple building blocks we can offer users a list of actions that are available for a specific object:

Completely discoupled

The major advantage of our solution is that we do not hard-wire which portlets offers what to other portlets. All you have to do is insert a service invoker into the UI and the framework does the work for you. All people working on the project can work in parallel, the communication overhead is minimal. All the developers must do is offering a portlets services using the framework and give services a name that speaks.

This makes turns our product into a completely customizable platform that fits exactly our users’s needs.

Maximum flexibility

The framework makes splitting up responsibilities between portlets easy and puzzling just the right application for the job together possible. After adding a new portlet to a page, all service menus are automatically updated to offer new services that may have been added by the new portlet.

A generated service menu

Service menu for a different set of portlets

What you see in these screenshots is that depending on which portlets are available, the portlet will offer different actions for an object (for Screenshot 2, the “Ping” portlet was added). All information about which services are available is calculated client-side and for the current setup. Adding a new portlet will add its services to the actions list. The text that appears inside the menu is set by the portlet offering the service.

Invoking services is not limited to the context menus. We also use buttons for services that enable the creation of new items.

Impacts on portlet design

All this makes it easy to develop portlets that are designed to fulfill small tasks the right way. Reusability of portlets is massively increased. And on top of all this you get a consistent usage pattern that your customers will be familiar with when you are adding more functionality.

This is the third article in my mini-series about developing highly ajaxified portlets. In this blog, you can also find articles about:

• Using YUI loader for your own javascript modules
  
• Portlet namespaces and javascript

In my next post in this series, i will give a little insight into how we use metadata generated by our server to make creating a fully ajax portlet a breeze. Meanwhile, check out our posts about testing our Ajax frontends using Selenium and the YUI Test framework.

Eight month ago I posted this entry in german. After a comment that this post is needed in English, I will translate it and rethink if I would confirm my pro and con.

Could you compare Ajax and Flex? Sure! Both are technologies in the web frontend, which cover the same domain.

Should you compare Ajax and Flex? Sure! To learn more about the strengths and weaknesses and pull the right technology for the use case out of the hat.

What are the pros of Ajax?

• HTML, CSS and Javascript are widely known and there are a lot of people who have programmed with this languages
• The end user is very familiar with it. He knows the browser very well and knows how things are working, what buttons look like and where he could click, …
• There is no need for a plugin, because everything is supported natively in the browser (plugins could be a huge problem in controlled enterprise environments)
• Client and server side patterns are very mature and you get clobbered over the head with frameworks (in a positive way). Webwork, Struts (1 and 2), Spring, Turbine, Tapestry, JavaServer Faces, … in the Java world, YUI, Prototype, JQuery, Dojo, Ext, … in the Javascript world (to name just a few).

What are the cons of Ajax?

• It still is HTML with all its weaknesses. Rounded corners, small effects, browser incompatibilities, … … nearly everything is possible, but it is often laborious and not really straightforward
• Ajax is based on Javascript. At the beginning everything seams to be great. But then you realize, that you are just scratching on the surface and you are falling in a deep hole. When you are back at the top, you can see the strengths of the language
• The Javascript/Ajax frameworks are getting better and better. Two years ago there also exist a lot of frameworks, but they weren’t very mature or well documented in some parts
• The performance can suffer a lot of from the use of DOM manipulations. Sortable tables or other complex operations are working at limit of the practiable
• Browser and their technologies have evolved in the last years, but HTML wasn’t created to be dynamic.

What are the pros of Flex?

• Steep learning cureve at the beginning. After a few days you can create applications, which would take longer with HTML, CSS, and Javascript even after some years of training
• Sexy interfaces. A Flex application looks better at the first sight. Rounded and transparent layers, gradients just as you like them without complex scaling background images. Small effects just working after two lines of code and doesn’t have an impact at the browser performance
• Integration of multimedia data. A video player or a control to play MP3s, just a few lines of code. Clean and straightforward

What are the cons of Flex

• A Flex application looks like a Flex application. Not a big downside, but a designer needs to learn how to style it. Else you just got a 08/15 application, what can be a problem when Flex is spread wider
• Small application can be developed really fast, but if an application gets larger, you are loosing yourself in Flex. Frameworks like Cairngorm solving the problem but the learning curve is getting flatter and flatter
• I18N, automatic builds and code generation are possible but a lot of enterprise features are hidden very well. The community around Flex is growing but in a lot of areas you are alone with just a hand full of google hits
• Flex is generating Flash and the language MXML is in the opposite to pure Actionscript the strength, to get faster to your goals. But Flex is just on top of Flash and the separation of MXML and Actionscript is often to fluent, to be very homogeneous
• The FlexBuilder is no IntelliJ and the tools are still very unpolished. The development of applications is possible but it could be a lot better in some parts

Conclusion:

If you need a multimedia application with some content which should look very nice, then Flex fits very well. But if you want to manage data and you want a wide support for your application, then Ajax is still the better choice. Flash still feels like a foreign object in the web. Deep links, copy of content, loading time and the existing knowlege and usability of HTML are arguments against Flex. But if the web application should feel as close as possible like a desktop application, then Flex is a good way and maybe the AIR technology is the goal. When developing a touchscreen application we also had the decision between Flex and HTML. I think it was a good choise to try Flex because of the interface speed (no page rendering) and the missing page reloads. It feels more natural for this kind of product.