Slashdot Mirror
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."
Real Men code html by hand, in a text editor
[Fuck Beta]
o0t!
Hm. Tapestry is an open source project; from the FAQ:
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...
The Army reading list
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.
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
No! :(
The post looks like an ad.
I have used Tapestry several times since its firsts versions (pre-Apache). It sucks.
Yeah is much better than Struts and others, but is really complicated... a lot of XML
Why other frameworks like Seaside http://www.seaside.st/ doesn't receive the attention of Slashdot?
Seaside is technically superior, it uses continuations to mantain state and this make it really transparent...
Maybe because Seaside runs in Squeak http://www.squeak.org/, is open source and...
Wait is not sponsored by any big name (like IBM, or Sun)... mmm both IBM and Sun publishes its ads in slashdot...
Ahhh now I see why
Although I freely being influenced as a user of WebObjects back in the day (circa 1998 and 1999), that's about as far as the lineage goes. I certainly built Tapestry with a different set of expectations and compromises than WebObjects, and that has evolved further of the years.
However, I will stand by declaring myself "the original author of Tapestry". That clearly describes Tapestry design and implementation; the flavor might inlcude a little WebObjects spice, but the meat is pure Java + Servlets + Howard Lewis Ship's insights and contributions (and mistakes).
Now look what you made me do ... refer to myself in the third person!
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
* 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.
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!
This sig is intentionally left blank
I would just like to weigh in and place my X firmly in this "What a load of horseshit!" box.
The Java version of the BirthdayOrganizer backend, which I won't even bother linking to, is well... ginormous.
The author happily provided links to the python and PHP code but 'wont bother' linking to the Java source. Anyone who needs 3004 lines of Java over 45 files to implement a simple webservice is in the throes of a brain haemorrhage. I do love these kiddie blogs, "I wrote some crap Java code and look how crap it is, ergo, Java must be crap!!!11".
Java does have it's faults, but I advise the reader to seek out a better source of information. It can sometimes be difficult to be sure of the quality of a source of information but fortunately this blogger has made our job easier by using the word 'ginormous', clearly showing themselves to be a complete wanker.
Sun's java studio creator is now free. I'm not sure which "framework" if any it uses but it seems a quick and
e ator/index.jspe ator/reference/quicktour/2/flash/index.html
well though out way to created database backed web pages. I wonder if tapestry works with this or eclipse.
Sun is definetly feeling some heat from eclipse and starting to make it development tools significantly better.
If I wasn't using php I would definetely look into thses.
http://developers.sun.com/prodtech/javatools/jscr
http://developers.sun.com/prodtech/javatools/jscr
My own current solution on my personal Web site involves doing a more limited version of that using PHP. I'm debating whether I want to try to move it to a Real Web Framework or not.
If you like Perl, you might be interested in Jifty, a new open-source Perl-based Web framework. It's only a "developer release" right now (ie. don't use it to run your banking site), but it's pretty useable all the same. It's got a lot of the shiny AJAX stuff people have come to expect, and it makes setting basic things up ridiculously easy, but it's also got a solid core foundation for database stuff. It's a pretty spiffy framework.
(Disclaimer: I work for Best Practical Solutions, the company that started Jifty.)
This gets modded Informative? Oh, the irony... it hurts.
Mods, just bogart that joint! My post (above) wasn't Informative . At best it was (dubiously) Funny . Arguably it was either Flamebait or Troll ; and it is now certainly Overrated .
See, these funny little words in the moderation menu, they all have semantic content, you know? Like, they actually mean something... Oh, never mind. As you were.
I'm old enough to remember when discussions on Slashdot were well informed.
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).
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind