Derek Hohls wrote:
Yes, he does (fair enough, he's an independant consultant) - and I think he makes his case *for* wanting to promote them very well - assuming he has had all the experience he speaks of...

I'd like to talk about my experience, if you don't mind.

I started using Servlets when they first came out. I used the very first versions of Sun's "Java Web Server" when it was the only container available, and boy how it sucked!

Of course, I did generate HTML with out.write("<html>") ... until I learned about ECS [1] and it seemed a great leap forward, at the time.

I hardwired SQL statements (using JDBC) in every servlet and did my own implementation of connection pooling.

Then I learned XML and XSL-T and did my first servlet that output XML documents and transformed them to HTML. It was circa 1999 and that application is still running today.

Soon after that, I learned about Cocoon (1.7) and discovered that I could have used it instead of writing all that code myself. So, I started doing lots of XSP+XSLT pipelines and my productivity went way up.

I hunted this particular type of chicken for a few years, while the elephants loomed on the horizon, but I stayed far from them because the applications I was doing at the time didn't seem to require them.

But I grew dissatisfied with this kind of approach, because it wasn't properly layered and thus was hard to maintain. It still had hardwired SQL and thus was hard to maintain. It wasn't object-oriented and thus it was hard to maintain (at least IMHO). Productivity was good for simple applications but didn't scale when complexity grew. Splitting logic between the sitemap, sitemap components like actions and XSP files didn't look very elegant. It wasn't much fun, either.

Then, about two years ago, I started toying with ORM tools, which elegantly solved the problem of encapsulating data access logic, a thing that I had struggled to do since I started programming in C and C++. I chose to go with Hibernate and haven't regretted that decision since then.

At about the same time, Cocoon's flowscript came out and I was completely blown away! You have to admit it's a fscking brilliant idea. I immediately converted the whole team to using Flowscript together with Hibernate and the results started looking promising, even though our first delivered application suffered from performance and stability problems caused by the immaturity of the tools and by our own ignorance about them.

It's been a real Copernican revolution for us and, since then, we've seen a steady rise in developers' productivity. We've recently added Woody (CForms) and later Spring (just the ORM support at the moment) to the mix: having your transaction demarcation managed declaratively is a big plus.

This is the path that brought me to this point and no, I don't regret it. Flowscript, CForms, Hibernate and Spring form a basic set of weapons that we use in *every* application we do, even if it's quite simple. I've seen developers grasp them in a very short time and be productive very fast, so I see no point in suggesting "simpler" alternatives. This is not big game: this is game that can be as small or as big as you like, it just fits very well to a wide range of problems.

Now, there's one thing that actually bugs me. It's the fact that I am using very little of Cocoon's traditional components and traditional way of doing things. No XSP, no Avalon components, our sitemaps are reduced to lots of <map:call>s and a few pipelins for rendering views (basically just a fixed template), the only kind of generator we use is JXTG. I'm starting to wonder whether Cocoon's dual nature, an XML-based publishing engine living together with a rapidly-evolving Web application platform, isn't dragging us down. And I'm also starting to wonder whether this duality will cause some friction in the community, in the near future.

But this might be the subject of another thread. This message is too long already.

        Ugo

[1] http://jakarta.apache.org/ecs/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to