Comparing Tapestry to CEP

I am sure my co-worker as well as my cohort are sick and tired of hearing my comparisons, but as I start developing with Tapestry I can’t help but see some striking similarities.

The first similarity is that both Tapestry and CEP set out to provide web developers a way to develop component-ized/modular applications that emphasizes code re-use. CEP was born out of a desire to develop components out of components that can then be re-used in multiple parts of the application by just calling the component. My very first implementation of this was on the now-defunct cataBlog in 2001.

About a year ago I registered Core Enterprise PHP at Sourceforge so that Marcus and I could implement the next generation of this modular “framework”. We have been developing CEP and developing in CEP ever since.

CEP turned out to be vastly different from cataBlog. CEP gave us a clear way to separate our code. We developed a component life-cycle that took place for every module/component that was active for a request. We were able to stop thinking about URLs and pages and start to think about events and components. One of the most important aspects of CEP was that was that it was object oriented, and this allow us to hide much of the complexity from the application developers. From what I hear, this complexity mask has be very helpful in allowing developers to work on a CEP project without having to know much more than the business problem and how to write PHP.

We have decided to give Java a try for some projects at work. When we first started looking at Java I was very unsatisfied with the development methodologies that were feasible for a small team. I wanted to be able to develop modular applications in a object oriented way, and I didn’t want to think in terms of URLs and top to bottom page rendering. I didn’t even want to think about pages. When I first looked at Tapestry I saw a tag-based WYSIWYG language similar to ASP, JSP, and most PHP. We even started to implement a project in JSP, which was very frustrating for me because it just doesn’t allow me to develop the way I have become accustomed (which I also feel is vastly superior to the way most “web apps” are developed. After taking a deeper look at Tapestry we decided it would be close enough and started to give it a try.

So what are these similarities you ask?

• Re-usable component based development
• Tapestry’s Engine and Visit objects provide similar functionality to the “Local Classes” in CEP which allow application-wide behavior to be defined/implemented once
• Tapestry may do a better job of it by providing listeners, but CEP also masked URLs using cepCreateUri()
• Components can include other components
• Application flow redirection without sending http headers
• Similar steps in the request processing (cepPreRender() vs pageBeginRender()

I will list more if/when I find them.

I should say this. CEP modules may be a little easier to develop than Tapestry components, and there is less of a distinction between CEP modules and pages than there is in Tapestry (meaning modules can be pages and pages can be modules with no alteration in CEP). Tapestry is hands down a more mature system.

There is also one thing I would like to see implemented in Tapestry (or figure out how to do it if it is already there). I would like for there to be an equivalent to EventState methods. In CEP, EventState methods are a way in which just be define a method you can add functionality to a particular state of a module/component. A good example is an add/edit form. In CEP the form can be defined in the module constructor and the in the edit state a renderEdit method would be called if it exists. This allows CEP developers to populate the form. Obviously there are ways to do this in Tapestry, I just think that the elegance of simply defining a method is simple and correct.

Having said that, I look forward to being able to post more things I like about Tapestry in the near future.

-Jackson

October 27, 2004. Uncategorized.