Though the Shell component in Tapestry has no parameters for setting META tags it features delegate parameter. The deletage must be of type IRender. When Tapestry renders the Shell component it invokes the following method:

void render(IMarkupWriter writer,  IRequestCycle cycle)

According to the documentation of the Shell component everything you write through the writer will be placed before the tag. Therefore it perfectly serves our needs for writing custom META tags! First thing you have to do is to write a simple custom class that implements the IRender interface:

public class MetaGenerator implements IRender
{
    private IAsset propertiesFile;

    public IAsset getPropertiesFile()
    {
        return propertiesFile;
    }

    public void setPropertiesFile(IAsset propertiesFile)
    {
        this.propertiesFile = propertiesFile;
    }

    public void render(IMarkupWriter writer, IRequestCycle cycle)
    {
        if (cycle.isRewinding())
            return;

        Properties p = new Properties();
        try
        {
            InputStream in = propertiesFile.getResourceAsStream(cycle);
            p.load(in);
            in.close();
        }
        catch(Exception ex)
        {
            log.error("Could not read properties file :" + propertiesFile, ex);
        }

        for (Iterator it = p.keySet().iterator(); it.hasNext(); )
        {
            String name = (String)it.next();
            String content = p.getProperty(name);
            writer.begin("meta");
            writer.attribute("name", name);
            writer.attribute("content", content);
        }
    }

    private final static Log log = LogFactory.getLog(MetaGenerator.class);
}

As you can see the class MetaGenerator has a property propertiesFile of type IAsset. This property can be specified in the decleration of the page:

<?xml version="1.0"?>
<!DOCTYPE component-specification PUBLIC 
    "-//Apache Software Foundation//Tapestry Specification 3.0//EN"
    "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">

<component-specification class="net.acidware.jtwaddle.presentation.component.Border" 
  allow-body="yes" allow-informal-parameters="no">
   <bean name="metaGenerator"
     class="net.acidware.jtwaddle.presentation.bean.MetaGenerator"
     lifecycle="page">
     <set-property name="propertiesFile" expression="assets.metaProperties"/>
   </bean>
...
  <context-asset name="metaProperties" path="meta.properties"/>
</component-specification>

That's it! :-)

After some weeks of work once again I ported my little weblog system :-) This new version is now powered by the following technologies:

• Tapestry for the presentation layer
• Spring as the container
• Hibernate for DAO
• Lucene for fulltext search (currently deactivated)

All in all I am very happy with Tapestry. Though it has it quirks as well it is still a great framework to develop with. It clearly features a very object oriented way of web development. I really like WebWork for its simplicity and effectiveness too, but it is focused around the controller. Tapestry, however, gives you, the developer, the possibilty to develop true web components. A component consist not only of a Java class but of a HTML template as well (in fact it consits of three files: definition, Java class and an optional template). Thanks to its concept of a markup writer it is very easy to manipulate the HTML code from Java. Some components for example can make use of a renderer such as the form component. If the validation of a form fails the renderer of the form marks the wrong fields dynamically by modifying the HTML code on-the-fly. Very cool!

Well, as you might guess, I am a great fan of Tapestry :-)

I am currently migrating to Tomcat 5 and my brand new backend powered by Tapestry! Stay tuned for more ...

Some days ago I've installed Gentoo 1.4 on my Dell box because I was sick of the RPM hell. The good thing is that Gentoo is up-to-date concerning system software packages. The bad thing is that Gentoo is up-to-date concerning system software packages? Err? Well, in case you are able to compile the sources on your own ... fine! But commercial software very often requires old system packages, mostly older versions of the GLIBC. IBM's WebSphere 4.0 is such a candiate (in fact the bundled JVM is affected) and therefore it requires some tweaking in order to run on Gentoo 1.4. After some investigation I found out that WebSphere 4.0 requires a GLIBC with kernel 2.2.5 support. Fortunately the GLIBC which comes with Gentoo 1.4 can support this feature. It is, however, disabled by default and therefore you must recompile the GLIBC. The following steps are required: [code] 1. Change into the directory /usr/portage/sys-kernel/linux-headers 2. Emerge linux-headers-2.2.20.ebuild 3. Drink some coffee 4. Change into the directory /usr/portage/sys-libs/glibc 5. Emerge glibc-2.3.2-r1.ebuild 6. Drink lots of coffee or take a walk [/code] Make sure that you do not have "ntpl" in your USE variable before rebuilding the GLIBC. Afterwards WebSphere 4.0 should run fine =)

Yesterday I compiled a project on my iBook and deployed the resulting jar files. Today the customer called me and told me that the CSV parser wasn't working anymore. After some research I found out that javac on OS X doesn't use ISO-8859-1 as the default encoding (I guess it uses MacRoman). Acutally the problem is that we have german umlauts in some of our source files. Therefore it is a good idea to specifiy the enconding property in your ant task:

<javac encoding="iso-8859-1" ...
...