Meta-Programming Page Content

Meta-Programming Page Content

It is likely that you have some cross-cutting concerns across your pages, specific features you would like to "mix in" to your pages without getting tied into knots by inheritance. This is one of those areas where Tapestry shines.

This specific example is adapted from a real client requirement: the client was concerned about other sites wrapping his content in a frameset and making the site content appear to be theirs. Not all pages (in some cases, that would be an advantage) but specific pages in the application. For those pages, the following behaviors were required:

  • Set the X-Frame-Options response header to "DENY"
  • Include JavaScript to "pop" the page out of a frame, if in one

Again, this could be done by having a specific base-class that included a beginRender() method, but I think you'll see that the meta-programming approach is nearly as easy and much more flexible.

Component Meta-Data

In Tapestry, every component (and remember, pages are components) has meta data: an extra set of key/value pairs stored in the component's ComponentResources.

By hooking into the component class transformation pipeline, we can change an annotation into meta-data that can be accessed by a filter.

Defining the Annotation

ForbidFraming.java

This annotation presence is all that's needed; there aren't any additional attributes to configure it.

Converting the Annotation into Meta-Data

This is in three parts:

  • Define the meta-data key, and define a constant for that key
  • Set a default meta-data value for the key
  • Set a different value for the key when the annotation is present

Our key is just "forbid-framing", with values "true" and "false". The default is "false".

Defining the Constant

FnordSymbols.java

Setting the Meta-Data Default

Next, we'll create a module just for the logic directly related to framing. In the module, we'll define the default value for the meta-data.

ForbidFramingModule.class

Mapping the Annotation

Most of the work has already been done for us: we just have to make a contribution to the MetaWorker service, which is already plugged into the component class transformation pipeline. MetaWorker spots the annotations we define and uses a second object, a MetaDataExtractor we provide, to convert the annotation into a meta-data value.

ForbidFramingModule.java (partial)

If the ForbidFraming annotation has attributes, we would provided an implementation of MetaDataExtractor that examined those attributes to set the meta-data value. Since it has no annotations, the FixedExtractor class. The argument is the meta-data key, and the default value is "true".

Plugging Into Page Rendering

The work we ultimately want to do occurs when rendering a page. Tapestry defines a pipeline for that overall process. The point of a pipeline is that we can add filters to it. We'll add a filter that checks for the meta-data key and adds the response header and JavaScript.

The service is MarkupRenderer, which (being a pipeline service), takes a configuration of filters (in this case, MarkupRendererFilter.

We contribute into the pipeline; the order is important: since the filter will need to write JavaScript, it must be added after the built-in filter that provides the JavaScriptSupport environmental object.

ForbidFramingModule.java (partial)

How do you know what filters are built-in and where to add your own? The right starting point is the JavaDoc for the method of TapestryModule that contributes the base set: contributeMarkupRenderer()

Implementing the Filter

Everything comes together in the filter:

ForbidFramingFilter.java

There's a bit going on in this short piece of code. The heart of the code is the MetaDataLocator service; given a meta-data key and a page name, it can not only extract the value, but then coerce it to a desired type, all in one go.

How do we know which page is being rendered? Before Tapestry 5.2 that was a small challenge, but 5.2 adds a method to RequestGlobals for this exact purpose.

Both Request and JavaScriptSupport are per-thread/per-request services. You don't see that here, because that's part of the service definition, and invisible to the consumer code, as here.

Of course, it is vitally important that the filter re-invoke markup() on the next renderer in the pipeline (you can see that as the last line of the method).

This code makes one assumption: that the fnord application's Layout component added fnord.js to every page. That's necessary for the JavaScript that's added:

fnord.js (partial)

Conclusion

That's it: with the above code, simply adding the @ForbidFraming annotation to a page will add the response header and associated JavaScript; no inheritance hassles. This basic pattern can be applied to a wide range of cross-cutting concerns, such as security, transaction management, logging, or virtually any other kind of situation that would normally be solved with inheritance or ugly boilerplate code.

Icon

The code in this example was designed for Tapestry 5.2. Some names were changed to maintain the anonymity of the client (whose project is still secret at the time of writing).