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.
Category Archives: class-transformations
A simple implementation of a
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.
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’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
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
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.
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.