I already made some experiences with the Flying Saucer on another job and it is still a very nice framework for PDF creation. For me, a major advantage of "The Flying Saucer" over other PDF creation frameworks, like XSLT and FOP, in the Web world is the homogenous technology mix.

"The Flying Saucer Project" create PDF from XML/XHTML pages using CSS style sheets. All technologies known to the web designer that gives your web site this pretty look. I guess it's okay when you say, that XSLT and FOP is the more powerful technology mix, but styling pages on this technology mix is not a simple task to do.

So back to the initial topic: A basic ingredient which is needed to create PDFs with the "The Flying Saucer Project" is some XHTML. In our project at scoyo we wanted to use Apache Tapestry to create this XHTML.

After taking a closer look to the Apache Tapestry rendering pipeline I found out, that the PageResponseRenderer is the perfect place to hook up the PDF creation into the rendering process. On the one hand the PageResponseRenderer uses a MarkupWriter to create the (X)HTML content from the current Page instance. On the other hand the PageResponseRenderer is responsible for writing the generated content into the server response.

Using the Apache Tapestry own IoC mechanism it's quite an easy task to decorate the Tapestry PageResponseRenderer implementation. It's a beautiful mechanism when you understood how it works. Okay I guess using the 5.1 version of tapestry it would be better to advice the renderPageResponse(...) method, but I had not enough time to get familiar with it yet.

One real big plus on Apache Tapestry is the implementation. Every function is well encapsulated into separate services. And the service implementing classes are very short and almost always on consistent level of abstraction. So you easily understand how a service works and you are able to copy and extend the service functions. So I extended PageResponseRenderer to determine if a page creates XHTML output which should be transformed to PDF. If no PDF should be created my PageResponseRenderer simply delegates to the original Tapestry instance.

When the page wants to create PDF my PageResponseRenderer buffers the created content and redirects it into the ITextRenderer of the a href="https://xhtmlrenderer.dev.java.net/">"The Flying Saucer". Okay this sounds more nice, than it actually is. The content is stored into a ByteArrayOutputStream and re-parsed by the standard JDK XML parser for further processing by the ITextRenderer. But I guess the we will live with the performance impact until it gets a real issue.

So long explanation short story. The whole thing worked out great! It took me like two to three hours to implement a first prototype. In out web application. This also includes the embedding of custom fonts into the PDF and a nice discovery of pages to render into PDF, via custom annotations using the component model meta-data facilities and a ClassTransformationWorker.

Web development can be so easy when you are using Apache Tapestry. On an earlier project we used a similar architacture with JSP and the "The Flying Saucer". I guess it took us ten times the effort to establish an equal infrastructure using JSF and the Java Servlet API ...

Due to the generosity of Google I got a nice Google wave test account. Now I am looking desperately to some spare time to evaluate the integration of jaev to the wave. One idea is to expand the validation to wave addresses via the wave protocol. Maybe an online validation as wave bot is another exciting idea.

The jaev framework is in productional use at least one installation and no major problems where filed so far. I'm keeping my fingers crossed

I am working already on some new features:

• Caching negative responses of mail servers
  When a mail server refuses communication due to suspected spam, the result will be cached to reduce network traffic.
• Suggest e-mail addresses
  When the validation fails suggest a list e-mail addresses. This algorithm may use the previous request and a default list of domains to compute some suggestions.

If you have any good ideas, file them on the issue tracking system or the google group.

Maybe I am applying for a google wave developer sandbox access to provide a google wave robot for online e-mail suggestion. Bah, that sounds like some work

Friday evening I read about the new version of JSF. The reference implementation (RI) Mojarra made an early draft review (EDR) of Mojarra 2.0 which implements the lastest specification of the JSR-314 which features JavaServer Faces (JSF) 2.0.

I don't want so summarize alle the new little gizmos in the JSF 2.0 spec or the EDR, Ryan Lubke does this in his blog already. There will be a long way to go to finish all the issues of the JSR but I can't stand to comment the one or other thing.

Like i.e. the project stage feature. Damn I am doing this like this for years in my application. It's a wonderful way to tell the application how many secrets have to be kept in this environment.
In a test environment I like the application to be very verbose and tell my of every little affliction, but in productive envorinments the application has to be very reticent. I don't want to tell the bad guys out there all over the internet about the flaws in the application.
One thing I am still missing, which goes hand in hand with project stages in my appliations it the version number. The application provides facilities to access the version number of the application and display it in any page. A wonderful tools to communicate with our QA department. They can check the version history if an issues was solved in the current version deployed on the test and QA system and they don't have to recheck about the version with me every time.

Another nice feature I noticed is, that in JSF 2.0 the component tree may be aware of the head and body areas in a HTML page. So it now should be quite easy to add CSS and Java-Scipts to a page. This may end some nasty implementations to re-parse the rendered output before it's send to the client to add CSS or Java-Scripts to the header. Or worse the tons of inline Java-Script code.
Let's be honest most of the HTML code generated by JSF is quite a horror and the frontend engineers are hating it a long time. Maybe we'll get some really nice HTML code now, so we don't need any more perfomace hacks to accellerate the bad HTML code.

I will keep an eye on the JSF 2.0 spec, it may solve much of the pain I have to today using JSF ...