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."
Please don't take offense with this, but Tapestry seems to be an open source version of NeXT's - then Apple's WebObjects web application development system. Even the Tapestry documentation acknowledges this.
WebObjects performed poorly in the marketplace due to Apple's stunning inability to market it's strengths - the exact same strengths the article is describing. Many people, including Apple employees - (myself in the past) - lobbied for WO to be made open source. We failed. Good to see that the ideas live on.
To be fair, when I hear a reference to the "Original Author of Tapestry" I do think its only fair to refer to the staff at NeXT, then Apple who developed this wonderful system. Tapestry is impressive in its own right, but seems more an extension of WO design principals rathen than a unique work. Such is the history of software design, so all's fair in the end.
And yes, I own your book, and think it's very well done. Tapestry is a great system, and can be recommended - but let's not forget the original inspiration.
/* Dang, I can't type that well. */
I have heard authors who swear that handwriting is much better than typewriting. Some people swear that they can tell if a story was written on a word processor. I have heard many complaints that Power Point tends to force presentations into a kind of mindless cookie-cutter kind of sameness. All these things are actually true.
What separates a good web page from a crummy one is not so much the tools that get used but the talent and knowledge of its author. The sad truth is that there are many hacks out there who won't produce good web pages no matter what tools they use. Easy-to-use tools do make it easier for talented designers to get up to speed quickly.
My experience is with the sign industry. In the good old days, a sign painter would work for years to perfect a 'font' which he could produce effortlessly with his brush. By the time he learned his craft he was probably a pretty good designer too. Then we got sign cutters (cutting vinyl letters with a plotter). Now everyone had the same set of fonts. Joe's Rapid Cheap Sign Place was competing with businesses that had been established for many years. Guess what? The good designers still command good prices. The hacks race to the bottom of the market; undercutting each other on price. As far as I can tell, web design is quite similar. Any high school kid can churn out a web page. Some of them are nicer than those done by 'professionals'. There's still a market for good work. The hacks can't do good work and people can tell the difference.
I think in real life it doesn't metter which technology you use for implementation to give results fast too much. Ofcourse with some technologies the results are faster than wiht another for instance PHP vs Java Servlet. But if you count time which you spend on implementation of user requirements and time which you spend by reimplementing functionality which user specified incorrectly, you can end-up with result that reparing taken most of the time in other words budget. In our company we solved this issue by creating prototypes with this tool PETRA (http://www.cleverlance.com/petra). Business analyst draws gui prototype by speed 20 pages per day. When he is finished he gives prototype to customer/user who clicks trough and expresses his changes. After making several rounds customer and customer is satisfied with prototype, programers finaly start coding. We expirienced that with this approach customer knows what will be delivered on the begining of the project. He saves money on change requests and we deliver real application twice faster. It isn't just rapid development what does delivering faster, but clear customers requrements rafined by prototype. Check out that tool, it realy helps.
For personal development i've set myself a directory of perl scripts that don't interact directly with live html (they aren't CGI's), but rather perform small web related tasks on a bunch of files. I still edit my markup in a text editor. Here is a taste of what I mean.
/> tag to before the 4th paragraph of a chunk of text and float it to right (by applying the 'right' class attribute to it).
... yuck!).
paragraph.pl: Replaces "\r\n\r\n" with "</p%gt;\r\n\r\n<p%gt;" to properly paragraph text.
image.pl: Let's me issue a command like "add madness.png 4 right" to add an <img
thumbnails.pl: Give it a directory, it simply creates a subdirectory called 'thumbnails' and creates a dump load of thumbnails of a specific size therein.
I have a few dozen like this organised into folders, some taking a filename parameter but most just slurp stuff in via stdin and spitting out via stdout.
For the most part, this suits my style of personal web development. I find it difficult and discouraging to finish a project and polish it off only to have it 'out of fashion' or hate it myself in a few months time. This method let's me idley write small scripts, almost out of boredom, and put them to use. Recycling code is made very easy as well.
Of course personal pages these days have to have a bit of flashy interactivity. For that I get away with as much as I can on the client side. For example, manipulating lists using javascript for fast navigation (no not using xmlhttprequest, just manipulating the DOM), this saves on dynamic server side navigation code (Think of how many URL's out there you've seen ending in something like 'index.php?page=login'
For real interactivity, commenting underneath photos for example, comments are written using a live (cgi) perl script to a flat text file and a cronjob at my webhost crawls the directory tree every so often, does some filtering and validation, regenerates the comments html, and deletes the source files. The comments HTML in included into the photo page then using a server side include.
Simplistic but.... sufficient for a geeks personal webpage?
I steadily advise anybody to run screaming in the opposite direction whenever they are approached by somebody trying to sell them a tool to "magically make all of the inherent difficulty in making computers do awesome thing vanish instantly!" Anybody who can fall for this pap the 100th time they've heard it also thinks there's a $0.02 pill they can drop into a gallon of water to turn it into high-test, there's a special pattern of crystals that you can sleep with to cure you of cancer, and that you really can turn lead into gold if only you build the right-shaped magnetic pyramid around it.
Bulletin: Easy programs are easy to write. Hard programs are hard to write. Language doesn't matter at all. No, I'm not kidding: at all. I've tried all the major languages and quite a few minor ones. There's difference in functionality between one language and another, true. That's because different languages were built to different specifications and purposes: so there are no kernels written in python, no first-person shooters written in assembly, no databases written in POVray, no 3D pictures rendered from SQL. But they are all exactly, precisely, completely as easy/hard as every single other, to ten thousand decimal places.
Development environments should be text editors for your first thousand projects, and then hedge into an IDE for shortcuts - but even in Glade, all it does is write a few lines for you - to make the widgets do anything, you'll *still* have to get into the text file and code it in with the keyboard *anyway*. I've literally timed myself using an IDE vs. writing pure code in Emacs - in every single last case, my time was only a few minutes shorter in the IDE, and that only in certain cases. That's because text editors can cut/paste, and run macros you can code once to make them smack out templates for you.
People who flame/disagree are welcome to do so, but I'm just talking from my experience and observation. Maybe all of our perspectives will change in ten years.
I just finished reading an interesting comparison of Java, PHP and Python over on Bob Ippolito's weblog. It talks about the implementation of a simple web service in the three languages. To summarise:
That's to implement the same web service.
Bogtha Bogtha Bogtha
You pressume that SQL database IO is all Rails is capable of doing. In fact, I am working on a Rails project which uses SOAP, LDAP, and SQL.
SQL database IO is all that the Rails ActiveRecord ORM is capable of doing 'as shipped'. You may be able to write (or find) wrappers for ActiveRecord to deal with other methods, but that is not the point. A good framework should provide all this for you.
When I use Java I use the JDO 2.0 persistence API. I can read and write objects to SQL-based relational stores, XML, CVS, Text files, LDAP and many other stores without changing a single line of my source code. I also have a rich query language (JDOQL) that I can use on any of these persistence mechanisms - even Text files! Why should I go backwards to Rails/ActiveRecord, which provide less than this?
Again, you have to give some evidence or anecdotes here.. I was around then, and some of the ideas were good and have been forgotten, others were bad and are being repeated today....
I have been programming since the 70s. I remember in great debate between dynamic languages and statically types languages in the 80s (it was Smalltalk vs C++ in those days).
I always learned that the best programmers "write programs that write programs".. you don't agree?
I strongly disagree. This can lead to 'clever tricks' code that is obscure and can only be understood by a specialist. For me the key thing is clarity, even at the expense of verbosity.
I think I differ from you in that I expect that a significant number of developers will always be novice and inexperienced.....
There will always be a need for developers. The lack of creative flexability that these types of systems offer will be their ultimate downfall.
This just in! 3 out of 4 people make up 75% of the population.
I evaluated both JSF and Tapestry for my latest project, with a slight prejudice in favor of JSF, and ended up choosing Tapestry ... by a mile, actually, and for some of the same reasons you mentioned: too hard to "break the mold" in JSF.
That's not to say that I haven't had some wrangling with Tapestry, but it was for genuinely unusual stuff. And it's a heck of lot more concise than JSF.
The Tapestry docs are rather mediocre; they're still a holdover from v3 in many parts, and make some things sound harder than they need to be. I wonder if you used Tap 4 on Java 1.5 to their full potential?
We're not being a very careful reader today, are we? "Language does not matter at all" in terms of "HOW EASY" to learn and to use. Use assembly to write kernel, or a C compiler. Use Python to write game. Both easy. Use assembly to write game. Use Python to write kernel or C compiler. Both difficult. Tool not made for purpose used. Use each language where it work best: make any language easy. Apply to HTML, XML, CSS, Javascript...
On the plus side, they can possibly (and sometimes live up to the promise of) saving you the trouble of writing boilerplate code (e.g. db access, ....). They're far better than what would be hand-coded at shops where competence is, shall we say, less than common. My relevant horror story here was a job I walked into that had no definitive version of the source, no source code control, and developers just out of school given open-ended assignments to make this or that work with no supervision or code review. Lots of random SQL in jsps, a real mess. In a situation like that any framework is a godsend (any kind of architecture is better than none).
Another positive is that you can learn a fair amount about architecture and patterns from using them - one of the things that made a fair impression on me when reading about patterns was the statement that other professions, like architecture, train people by having them emulate and study the works of professionals, and the complaint that there were no software masterpieces to study. A budding architect studies Frank Lloyd Wright's FallingWater. What does a budding software developer study? Maybe frameworks are the beginning of an answer to this question, as you can absorb a fair amount of architectural principles through working with them.
On the minus side, I'm starting to see these things done as a sort of orthodoxy, and often they just add unnecassary layers to the code because "that's the way you're supposed to do it". You can often spend more time twiddling with the framework to get it to do what you want than it'd take you to write your own. My relevant story here is the day and a half I spent last week trying to figure out why my hibernate setup wasn't working properly, until I finally came upon a little note somewhere in the docs that it had problems with SQL Server and wasn't recommended. This is, BTW, for read-only access to the database, hardly worth the bother. (Of course, It's entirely possible that I was configuring it incorrectly in some way, didn't have the time to research it further, which is part of the point of the bother of it, there's a fair gap between learning it enough to get by and knowing it thorugh and through, and one rarely has time for the latter).
Generally my problem with them is that they tend to black-box the solutions they provide (which I suppose is sort of the point) which is great if it works exactly the way it's supposed to and leaves you wasting enourmous amounts of time if it doesn't.
A related issue is that they can make debugging and code tracing much harder. A Spring app, for example, links code through config files. Even if you understand the config files, you add a layer of indirection to code tracing. If you don't it can be almost impossible to figure out how this piece of data gets onto that page.
They're neccessary, I suppose, and good for something, but should be swallowed with a bit more salt than they generally are in the industry.
I still diagree. I know people who can throw together a PHP page but would have quite a bit of difficultly with even a simple assembly program. Hell, even I thought assembly was daunting back when I gave it a go. Anything that has a very cryptic syntax is going to be tricky to learn. Some languages ARE easier than others even in their intended contexts. The context itself influences how easy or difficutl a language is. A lot also depends on the way a particular individual thinks. A procedural language might be much easier to work with than an OO language for some people.
What happens when two languages are intended for the same purpose? Is it not conceivable that one might be easier than the other? Are you suggesting that it isn't possible for someone to come up with a really clunky and difficult language? I know I can name a few.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
- I'm just sick of people complaining about "Java" when what they're really complaining about is "Java abuse."
I remember this argument being used a lot by people defending Perl. A worrying sign for any language.Generating XML and transforming it via XSLT on the server is plain stupid. I have never seen a project which required this extra flexibility and justified the huge overhead of using the ugly XSLT. Piping the XML to the client and doing the XSLT transformations there might be ok in cases where bandwith is of importance.
Here is an example, so you can say that you have 'seen' such a project. Sometimes it is useful to generate XML because it can be selectively transformed by XSLT to a variety of report formats as the user requires: XML+XSLT can output RTF, or it can output XSL:FO which can be rendered as postscript or PDF, which can be returned to the user. The same XML output can be transformed into these different formats simply by supplying a different XSL stylesheet. This is simple to use.
XSLT processing can be very efficient, and to say XSLT is 'ugly' is simply a personal aesthetic judgment, and not of any value in judging how useful or fast it is.
All these frameworks limit testing capabilities and move things away from the compiler to the runtime. EL expressions, JSP taglibs, Beans using Reflection, huge XML configuration, XSLT and so on are all evaluated at runtime and none of this can be checked by a compiler.
This is simply not true. A good IDE (like Eclipse) has plugins that can check the validity of most of these before runtime.
Aw, they're so cute when they're bewildered! How can I resist? Hey, I'll spare this much for you: I know a secret. It's a secret you only find out after programming for a while. It's one you obviously don't know. You might as well have included a screen shot a couple posts back showing you googling for "programming language". Congratulations, you now know the names of several.
There is this public perception, unanimous in user-land, and even permeating to the very depths of Slashdot, which goes: "Computers are only hard because evil computer programmers deliberately set out to make them hard." And the secret is: that that's a falsehood. Computers are not made artificially difficult. It does no good to tell you this; this is a special kind of secret that you can only learn through experience.
The experience of struggling to design a usable user interface for your own system. The struggle to overcome the barriers of closed systems, lack of documentation, and misinformation everywhere you turn. The exasperation of dealing with users who come to you with the attitude that your program broke on purpose, you should fix it without knowing what the error was, and it's too hard to learn anyway because you make it difficult, because you're "evil".
Programming experience erases that mental line drawn between user and programmer. You get experience on both sides of the fence, and eventually you see that there is no such thing as artificial complication. Interfacing with a machine upon which we have taught electricity to think and where we hope to make it sing and dance for us is inherently complicated TO START WITH, and the various tools we use to perform our tasks - why, each and every one was written by average people like you and me who also sat down with a clean file and furrowed their brow and wondered "How can I do this? How can I make it so people will use it?"
No, you still have that mental mindset that there are programmers who deliberatly design things to be difficult, that it's all in spite, that they're laughing at you. Who, except as a joke, would deliberately make a programming language "hard to learn"? To fail at your task and blame your tool is simply a form of denial so that you don't have to face the fact that you have given up on trying to use something (no matter if it's COBOL or Javascript or Perl or freaking TECO, even!) that hundreds of other people have used successfully.
There is no "easy". There is no "hard". There is only "Task".