Category Archives: class-transformations

Tapestry source code viewer

A simple implementation of a SourceCodeViewer would be to have a service for adding and listing the source code and a component to display it.
Continue reading

Some Reporting tricks with class-transformations

Every time I used to see some duplication of code, I used to move that code to a new method. With Tapestry, you begin to think differently. Now every time I see duplication, my first thought is “Can I create a worker for it”.

In my current project, I am using a few new ones. So I thought why not share them with you.
Continue reading

Tapestry Mixins & ClassTransformations

Tapestry‘s Class Transformation can save you a lot of time and can show you clearly why it is better than inheritance most of the time. This blog has many examples of it. I just finished a new one. Here is the scenario. I want a label to have a title attribute(simple tooltip) which is to be fetched from the message catalog of the corresponding component/page. This is not that difficult, just create a mixin. But what if you want all labels to have this feature, even the ones you have no control over like the labels in BeanEditors. Continue reading

Tapestry Magic #14: Easy Selection

Tapestry’s select component is very flexible and this flexibility comes at a small cost. One has to pass a SelectModel and a ValueEncoder as parameters to the Select component. This seems too much work for simple use cases. With the help of class transformations, we can always find shortcuts. In this post, I will mix some of the useful techniques mentioned in the Wiki to make using Select component easier. Continue reading

Tapestry Magic #7: Tapestry Integration With Perf4J

Perf4j is a set of utilities for calculating and displaying performance statistics for Java code and has already been integrated with AOP’s like AspectJ. So I thought why not with our own Tapestry5. Won’t it be nice if we are able to annotate an event handler or a service method with @Profiled and Perf4J will log the details of its duration. That is exactly what we are going to do. Continue reading

Meeting Plastic II: Simple ChainBuilder

This is a simple implementation of a Chain Of Responsibility or Chain Of Command design pattern. We already have such a service in TapestryIOC and I thought of implementing the same in Plastic.

In Chain of Command design pattern, we create a single service from a set of commands which implement a common interface. This pattern can be provided out of the box by using Class transformations. The assembled service will run all the commands in the given sequence unless any of the commands throw an exception. I am keeping the example simple by forcing the methods in the command interface to return only void.

Continue reading

Meeting Plastic I: Introduction

With Tapestry, you know things improve very fast. For the users, everything stays much the same(Ok, only after Tapestry5) but for developers, it keeps you on your toes especially if you are constantly peeking into the source code. In Tapestry 5.3, we are going to see complete replacement of Javassist by Plastic. It is a wrapper around ASM.

Continue reading

%d bloggers like this: