Tapestry Making Web Development a Breeze?

An anonymous reader writes "IBM DeveloperWorks has an interesting article on how to simplify your Web-based development with Tapestry, an open-source, Java-based framework that makes developing a breeze. The article shows you around Tapestry, from installation to file structure. See for yourself how Tapestry facilitates servlet-based Web application development using HTML and template tags."

Comments

Re:Pathetic.

[tcopeland]

> Do the "editors" even try to pretend that these aren't blatent ads any more?

Hm. Tapestry is an open source project; from the FAQ:

Tapestry is open source and free. It is licensed under the Apache Software License, which allows it to be used even inside proprietary software

So I'm not sure that this really qualifies as an ad. More of a "free, informative article", especially since the author (Brett McLaughlin) is quite a Java guru.

Looks like Tapestry uses annotations a lot; I've found them to be pretty handy things as well...

DeveloperWorks is supporting open source community

[TapestryDude]

As the original author of Tapestry (but not the article on DeveloperWorks, which caught me by surprise) I can say that IBM doesn't have any secret agenda on this. In fact, given that IBM is selling a commercial product that competes head-to-head with Tapestry (their JavaServer Faces, built on top of their WebSphere proprietary Eclipse IDE) it is enlightened of them to cover Tapestry.

Of course, what's going on there is two fold. First, IBM is big enough that different areas of the organization will have different and occasionally competing goals. Primarily, all on-line magazines are constantly hunting for new material to keep the eyeballs looking (and the click rates clicking). IBM doesn't solicit authors to write on particular subjects, they accept existing authors efforts, with the authors pursuing their own interests. Here, Brett happened to be into Tapestry and did a great job providing additional documentation in the form of this article.

I make my living off of Tapestry, so I'm happy to see this kind of coverage, but the framework itself is open source and free, with a very, very liberal license (ASL 2.0). I make money by providing Tapestry support and training. There's your ad.

In even newer news, Tapestry 4.0 final release is now available.

Re:Easy web development with Java?

[Decaff]

        * 117 lines of very liberally spaced Python code, or
        * 138 lines of insecure PHP code, or
        * 3004 lines of Java code in 45 files, 29 lines of SQL, and 246 lines of XML configuration in five files.

Which is complete nonsense, as with Java you can use JSP tag libraries, which will are secure (compiled, so no code injection at run-time) and can be used in exactly the same way as PHP, so will require about the same size of code.

Re:Easy web development with Java?

[AlXtreme]

Lets just, for the sake of clarity and shameless Python-fanboyism, ignore the fact that the PHP code was properly commented (about a third of the 'code') and the Python code had a whopping 1 (one) line of commenting. Not to mention the PHP code had extra newlines adding to the readability of the code, and about half the code was a (very neatly indentend) array for some external library. Wake me up when you have a proper comparison.

Don't get me wrong: I love Python. But it doesn't need flawed statistics. Heck, I'd think a maintenance programmer would love the PHP code easily over that Python mess. (K)LOC don't count people, your use of commenting and clear code does!

Re:Tapestry drawback myths

[TapestryDude]

1. Complicated. Uneasy to learn.

Just different. People trying to find Struts++ get confused because Tapestry is a completely different beast.

2. Does not support unit testing.

Wrong. This was doeable in 3.0 with an add-on; an improved version of the add-on is part of Tapestry 4.0.

3. The "Model" component of MVC is closely tight to "View"; you cannot have many views of the same page (for instance: web page, web page for printing, WAP page).

Ultimately, your model is really DTO, not your page or component class. Tapestry components don't care where data comes from, thanks to OGNL. So, there's no reason you can't have multiple pages for different formats. However, Tapestry does not address the myth of one page / multiple views. A desktop HTML application and a WAP application are completely different beasts and should be treated as such. You should not be coding applications inside a big case statement.

4. Adding your own JavaScripts suxx. You have to map component names etc.

Because HTML output is componentized, JavaScript generation for that HTML must be componentized. This is an annoyance for simple cases, but means that complex cases just work. You can have as many DatePickers or Palettes or validating fields and forms per page as you like and it all just works with everything wired together properly, and all client-side elements (JavaScript variables and function names) generated free of naming collisions. Tapestry was born to do Ajax.

5. If you want to validate form field, you have to use special components (ValidField). Some components do not have their validated counterparts. Client-side validation is very basic (e.g. cannot check if entered date is in the future).

You haven't looked at Tapestry 4.0. Paul Ferarro did a complete rewrite of the validation subsystem to make it more powerful and more flexible; all the form control components now support input validation, ValidField has been deprecated.

6. Changing one line of code/template requires you to redeploy whole application; that is, pack it into .war archive, send to web server, perform refresh. When used with Apache Tomcat, leads to memory leaks.

So you're blaming Tapestry for your bad development model? I deploy into Tomcat, but do all my development inside my IDE using Jetty. No redeploy, and I can bounce the Jetty instance in a few seconds.

7. The page pool model is said to scale well, but can be very error-prone. For instance: if you forget to reset some variable, it can be displayed by some other user when he happens to pull it from the page pool.

This I find an amazing observation; Even Tapestry 3.0 supports transient and persistent properties for you ... meaning you write an abstract class and let Tapestry provide the code to implement the property along with the compliance code to work well with the page pool. Management of transient and persistent page state is an application concern that you should be delegating to Tapestry. Just define abstract getters and/or setters, rather than instance variables (and getters and setters). Tapestry writes the code for you (at runtime).