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."
>The solution is definately more involved than the problem.
I'd love to say "amen to that". I hate frameworks.
But the thing is, there are often classes of problems to which these things apply. It's just that you and I dont have them. A framework is a tool; use it when it suits.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
Scaffolding is a tiny portion of Rails, only a few dozen lines of code out of thousands. There's more code wrapped up in pluralization than scaffolding yet for some reason everyone's remains fixed on "scaffod :foo". DHH has said time and time again that scaffolding is there just so that you can get a quick way to get you running, by the time you're done the scaffolding code should be long gone.
Think of it as the 'genie' effect in OS X: easily recognizable but mostly for show. People may not 'get' things like Unit testing, database agnostic schemas, MVC patterns, domain specific languages, duck-typing, or any of the other things that make rails really productive but they sure as hell get "1 line of code and I've connected to a database to perform CRUD functions." Once you've got them with the scaffolding hook people are receptive to the things that really make Ruby on Rails cool.
Scaffolding makes for a nifty screencast but the real joy comes when you actually learn how to use the language and framework.
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
IMHO, this article is really poorly written. When reading an article on this kind of topic, I want the first couple of paragraphs to tell me what is new/unique about this tool. Instead the author wastes endless column space describing how to install the software, then more space describing the sample applications that you could look at yourself once you downloaded it anyway. I want to be given a reason to try it out: What makes this tool powerful; how can it save me time/help me to produce cleaner code? Maybe he got to this by the end of the article, but I had given up by then.
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
Rails has a lot going for it, and the entire Ruby concept of focusing on code has influenced many frameworks, including Tapestry. Tapestry uses abstract properties combined with annotations (or auxillary XML files) to do the kind of meta programming that is done using class methods in Ruby, but nonetheless.
In terms of dependencies, being an Apache project causes some distribution problems w.r.t depenencies, especially when you use non-Apache projects like OGNL and Javassist. The next major release of Tapestry will build using Maven, which will make nearly all of part 1 of this article irrelevant (or at least, standard). I'm looking forward to part 2 myself, which should identify why Tapestry is so special.
Finally, within the Java community, Tapestry is fairly well known, though a regrettably small percentage have used it. The majority of the targetted readers of this article would have objected to wasting too much space describing Tapestry and its goals, just as others in this thread have objected to the lack of that introductory material. You can't please everyone (exception on Slashdot, where you can't please anyone).
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
I realized long ago that frameworks were a waste of time, I'd already authored several by then. The last framework I wrote generated static html and now we just edit these pages by hand or write simple shell scripts. The solution is definately more involved than the problem.
Not necessarily. The right framework can produce the HTML for you, and can save you a lot of time because you can use components that generate things like fully-tested portable JavaScript. Some frameworks allow a lot of re-use. JavaServer Faces (JSF) will allow the possibility of rendering HTML, XML, WML or a range of other client presentation technologies from the same tags.
The solution may only be more involved that the problem is simple, and it is hard to tell when a problem will grow to be complex. Using a framework can not only save time but can be a form of insurance against future growth in complexity of the website.
* 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.
I've worked with Tapestry. Is it a decent framework? Yes. Did we end up choosing it over JSF for our project? Yes, we did. Did it make development "a breeze"? No.
In my experience, Tapestry simplifies some complex tasks and helps you write reasonably clean, well-structured code. This is, I think, all anyone should realistically hope for from any framework. However, it isn't a magic bullet and we did find that things became a little gnarly as soon as we tried to do stuff that the Tapestry developers hadn't really anticipated or designed for (and the things we were trying to do weren't really very exotic).
Of the frameworks I've seen lately, Ruby on Rails is the one that bends the curve the furthest in the trade-off between 'what you can do' and 'how easy it is to do it'. Tapestry is a way behind that, but it's nevertheless a solid addition to anyone's toolkit, so long as you don't have unrealistic expectations of what it can do for you.
Meaningless tautology.
Language doesn't matter at all.
Baseless assertion.
There's difference in functionality between one language and another, true. That's because different languages were built to different specifications and purposes:
And here you contradict your own baseless assertion.
no first-person shooters written in assembly,
Ok, here is a good example. Lets say all you had was assembly language and perhaps FORTRAN to perform some "high level" math operations. Lets say someone asked you to create an FPS. Now, it could probably be done. You'd have to figure out how to interact with the graphics hardware at the register level. You'd have to write almost every single function by hand from aside from whatever math functions you can utilize from FORTRAN. So 6 months into development someone comes along an says, "Hey, here is this new language called C and a library called OpenGL. These will make your FPS development a whole lot easier. It solves the really hard problems of dealing with hardware and makes your code work on many different kinds of graphics cards." Are you saying that you would run screaming from this offer because it couldn't possibly make your work easier? Unless you are some really f'ing hardcore assembly programmer, I bet you coudl cut your development time by an order of magitude at least. You could probably even afford to complete dump that previous 6 months of development in the trash and STILL come out ahead because you found a new tool/language which makes a perviously hard program relatively easier.
Contrary to your initial baseless assertion, language DOES matter. Frameworks matter. Libraries matter. There are, in fact, all kinds of things that can make a particular project easier.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
I agree with the sentiment of this comment -- but Escherial, I think you saw the word "rapid" and made a bunch of bad presumptions about Tapestry. Tapestry is not a crutch; it is an excellent framework, one you're obviously ignorant of.
What Tapestry is emphatically not is a whizzy-ooey drag-and-drop autogenerated no-coding-necessary whiz-bang shill. Those are, by and large, a bunch of crap: they usually just make the easiest 90% even easier, and the "last 90%" even harder.
What Tapestry is is a very nice web framework, which has a lot of the same MVC capabilities as Struts and the code reuse possibilities of JSF, with far less configuration and unnecessary complexity than either of those options. The Tapestry team, much like the excellent Rails folks, have looked for ways to reduce redundancy, boilerplate code, and messy configuration -- especially in this 4.0 release. Roughly speaking, Tapestry is about 80-90% of the streamlined simplicity of Rails, but with a much richer framework underneath and all the existing libraries and machinery of Java at your disposal. It has the best mechanism for HTML fragment reuse I know of.
What the Tapestry team has not done is try to make an app that thinks for you. You've still got to code. It's just a lot less tedious than with most other frameworks.
My two latest webapps have been all Tapestry 4, and it's great how little code/config I have to write that isn't conveying useful information. I'm really quite impressed with the framework.
So yeah, I agree with your rant, but it's not appropriate to Tapestry.
...will people stop pretending that "Java" is one giant monolithic thing that only works one way.
Look, these flagships specs like J2EE and EJB are designed to solve problems of writing massively distributed apps that need to have transactions spanning multiple servers running different OSes -- horrendous problems that you never, ever, ever want to have to solve. And if you do have to solve them, Java is the best way -- but if you take all that machinery and try to write a "hello world" webapp, of course it's going to take 30 bazillion lines of code.
Somebody writing the webapp he describes in 3000 lines of Java is either (1) utterly ignorant of how to use the Java frameworks (like Tapestry) that are appropriate for the task, or (2) deliberately spreading FUD on behalf of Python.
That is not to slight Python or the framework he's using. Python is very cool. I'm just sick of people complaining about "Java" when what they're really complaining about is "Java abuse."
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
Comment removed based on user account deletion