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."
Is it just me, or does anyone else feel that all the "rapid development" frameworks that are all the rage lately may be harmful to the current crop of new developers? There should always be a balance between development speed and flexibility, and I fear that crutches like rapid web development frameworks trade ease of use for the ability to do something novel. Of course, one can say "if you don't like it, don't use it", but the fact is that people new to the field will use it regardless, simply because it's the path of least resistance. True, some clever ones will extend the range of what was thought possible, but most will end up with the same cookie-cutter projects for which these frameworks are always tailored (look to scaffolding in Ruby on Rails for an example of the omnipresent "database browser").
I suppose this is just the next step in the constant progression toward appeasing laziness; no matter how easy an interface becomes, there will always be demand for something or someone to fill the gap of applying actual effort to learn it.
>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
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
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
pfft, web based tapestry making has been around for ages.
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
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
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 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.
This is no longer our father's web so why should our tools be our fathers?
Because they work.
KFG
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?
By the way, do you plan on releasing a new edition of your Tapestry book soon that is updated for version 4.0? I have the current version, but would love an updated version detailing some of the new stuff in 4.0 (like friendly URLs, something about HiveMind in 4, etc).
Don't be put off by the comments. If you already know about it, how to install it etc, this is not for you. But if you don't, its clear and informative and interesting. Looking forward to the next part.
I tend to agree with you. I'm not even much of a "web developer" at all. Rather, I occasionally get paid to put together a basic e-commerce or plain old advertising "shingle" site for a small business customer. And even for my needs, building rather straightforward "cookie-cutter" type sites, I would rather go with an existing PHP and SQL based template. Especially for things like online shopping carts, a big concern is always security. (EG. Has the solution/template been used extensively and tested for flaws that would allow a customer to modify the price of an item during checkout, or to gain access to other customer's information?) The PHP based e-commerce "store" scripts seem to have the best odds of being widely used, tested, and debugged.
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
I am aware of the dangers associated with poorly designed rich clients, but rich clients work well, as long as you use some discipline in the system architecture. I know some rich client architectures exist, such as Curl, but in general, it appears there is very little activity in this arena. I wish this industry would focus a little more on interesting GUIs, instead of beating the same horse over and over again.
He says it takes 3004 lines of Java code, but he won't link to it. I don't think Java is 30x larger and unless it's available for inspection, it's just a bunch of hot air.
Unbelievable. All the guy says is what worked for him and he's happy with it, and for this he draws such ire. Maybe he's not replying because it's a waste of time to enlighten a rock.
"No, it is because systems like Squeak, no matter how technically wonderful it is (and it is!) is not a production-ready system for high volume websites."
Well Squeak may be, but since Smalltalk is Smaltalk. Dolphin Smalltalk is commercial grade software used...commercially. The problem is more marketing and mindshare than any technical deficiencies.
Dolphin Smalltalk runs only on Windows. There are high-quality cross-platform Smalltalk versions, but the really good ones (such as VisualWorks), are either expensive of have very awkward licensing.
Smalltalk would be a great development system if there was a high-performance cross-platform version that was free or open source.
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
You'll quickly learn that the watchword in Tapestry is simple. That's not simple as in primitive or lacking sophistication, but simple as in easy to understand, usable, and intuitive. Because installation is your introduction to any new technology, it goes without saying that installing Tapestry is very easy
and this before a 4 page explanation of how to install.
Without a doubt web development could use simplification, but if they can't even simplify the installation process to less than four pages, how can they simplify the web? Seems they have some interesting ideas, though.
Qxe4
* 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.
Hey now, my legs work too. That doesn't mean I'm going to walk from LA to NY. It does mean I walk and use a stair-stepper. Agreed that people should code by hand to keep in shape, but don't look down at the corporate jet when we have a meeting a long ways away, saying, "I think I'll just walk."
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.
but when you want to do something more advanced like variable number of input fields... you have to fight it and create workarounds. I really prefer something more low-level as PHP.
No need to leave Java to do this - JSP has the same capabilities.
Huh, the python and PHP versions don't use SQL? Then why does Java?
don't look down at the corporate jet
.when we have a meeting a long ways away, saying, "I think I'll just walk."
That's your father's tool. Yours is video conferencing.
. .
I bicycle.
KFG
Z Object Publishing Environment (ZOPE) http://www.zope.org/ and its derivative Plone http://www.plone.org/ seem like they have all this and more. Like they are a whole universe. What does Tapestry have that Zope/Plone doesn't? -- IV
http://www.LinuxMedNews.com Revolutionizing Medical Education and Practice.
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."
Despite the nay sayers below, I have done Perl, PHP and Java for web services...Java takes A LOT more code to do the same thing. So, I agree :)
"He was a wise man who invented beer." - Plato
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
The numbers seem a bit off, but Java is a wordy language. The servlet api tends to make you code much closer to the protocol than you should need too. The lack of a standard web framework for java makes things very difficult. Every other language tends to have one way to do things at the basic level and with java you are stuck learning a few frameworks and pray you don't have to switch.
.NET developers agree on that point. Unless you are doing a major release (4.x to 5.x), there should be no major changes to the api that break things. Remember php is a language! Each time there is a change, its usually easy to fix but means there is non stop maintinence on web apps. It certainly makes it hard to sell them doesn't it? Your customers upgrade their server and break their software, etc. Your hosting company decides to patch a security hole and upgrade.. now customers sites are down. One can complain about microsoft, but at least asp apps tended to work when new versions of the language came out. IIS 4 and IIS 5 could both run my sites for instance without any changes at the time. I upgrade tomcat and my java servlets still run ok. I started on 4.x and now run on 5.5.x! Its not an open source problem because tomcat works.
Java based web apps take longer to code in my experience. I dislike php and haven't found time to play with ruby on rails or python. I also dislike jsp as a view technology.
I think the problem we are seeing with web technology is that there are two types of programmers. We have the hobby or asp era web app developers who prefer scripting and we have the bulky framework keep my job by adding complexity since real app development is dead type. In reality, the ideal model is probably somewhere in the middle. Scripting for views and easy stuff and something more framework like for web services and other things that require performance or a lot of code. (where scripting is slow) I like ASP.NET to some degree because its somewhere near the middle. I learned to code with vb and classic asp in the late 90s so I have a bias toward Microsoft on development. I think they provide some of the easiest development environments. I think the lack of classic asp scripting has forced hobbyists into php though.
I'd like to see someone create a good balanced environment with a scripting language and a framework for things like web services and ways to use code written in other languages (like C++) easily. I don't think we'll ever have that again.
As for tapestry, at the time I tried to learn it when it was just switching to be an apache project, it had the worst documentation ever. From what i've seen lately, the apache project still has that problem. Apache 2.0/2.2 aren't well documented systems and most of the jakarta projects are an order of magnitude worse.
In case anyone is wondering why I hate php so much, read the change logs. Code written for one release does not work on the next way too often. I don't just speak of the php 5 migration but of the 4.0 vs 4.1 vs 4.2 etc changes. A good project does not break their api on a whim. Most java developers and
MidnightBSD: The BSD for Everyone
Everything that isn't spaghetti code has an underlying architecture. Frameworks are just standardized, generalized, pluggable versions of that architecture. Practically any off-the-shelf web framework you decide to use is going to be better than what you hand roll, assuming your site is bigger than 10 pages. If it is smaller than 10 pages, stay the hell away from Java and get a decent Perl, Ruby, or PHP framework.
A framework is less a tool than it is an entire toolbox and a methodology for using said tools. These things are almost always useful.
Comment removed based on user account deletion
Slashdot jumped the shark when JonKatz started posting stories here.
deus does not exist but if he does
IBM has been pushing Java pretty hard for a few years now and has contributed a lot to the community. They may very well contribute to Apache, but I'm not sure on that. The article above was written for IBM's developerworks site which has frequent articles on all of the technology and development tools that IBM have their fingers in, including Linux, Java, Open-Source, and quite a bit more. It's a cool site to visit every so often.
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.
Sorry for what must sound like a technical support question, but is it possible to run Tapestry in a lightweight HTTP server such as Simple? It uses the usual HttpRequest/HttpResponse API for dealing with requests and has a minimal footprint. Can I call something in the Tapestry API and pass it the request to render the page?
Or can anyone recommend any other lightweight Java HTML generation frameworks that don't require full-blown servlet containers such as Tomcat?
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.
Damn it! How many stupid links are you gonna make in your comment? You insensitive clod!
The lameness filter should be updated!
Coderz 4 Life
from TFA
So that's 117 lines of Python...and a library. And it doesn't say how big the library is.
Could any of these 3004 lines be considered/implemented as library files? How many lines of Java would it take then?
And this begs the question: who wrote it? It is possible to write secure PHP, as much as it's possible to write insecure python.
You can take yer apples and pears, and compare them up yer own arse.
Must be slashdot:
- Uninformed comment near the top? check
- Pointless flamebait modded to Score 5? check
- Disingenuous and patently ridiculous to boot? check
- Complete ignorance to the turing equivalency to all languages? of course
Wow. I'm making a study. Apparently in french:
"Voulez-Vous Couchez Avec Moi?"
In English
It has come to the attention of my biological subsystems that I find you sexually fit and attractive, and thus would like to engage in procreative attempts in order to further the expansion of my genetic sequences in the Hobbesian environment we live in. Do you find such a query to be to your liking and predilection?
Hey, I'm just your average shit and piss factory.
I second that.
Especially the XML configuration file can't be much bigger than 20 lines.
It should be something like:
140 - 200 lines of JSP/Java (for imports, package declarations, typed variables etc.)
29 Lines SQL
20- 30 lines XML Config file
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Real men do server-side scripting in PHP (well, the really real hardcore men code CGI scripts in machine code, but it is rather extreme) in a text editor.
01010010011001010110000101101100001000000110110101 10010101101110001000000110001101101111011001000110 01010010000001000101010101100100010101010010010110 01010101000100100001001001010011100100011100100000 01101001011011100010000001100010011010010110111001 100001011100100111100100101110
http://www.TheGamerNation.com/Forums
Ed, man! !man ed
ed is the standard editor.
KFG
They probably also tested Ruby on Rails, but didn't think a number like 30 would make Python look good so they left it out.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
I have no first-hand experience, but it seems to be lightweight (350K), embeddable and Tapestry is said to run under it.
If a giant oil company wanted an abortion, would W's head explode?
I think it's not just up to us web developers are pages good. I mean, I can make technically good page that is well done. It isn't necessary same page or site that is good to use.
After all, customers may have their own ideas and needs that aren't good, and customers are always right.
Depends what one does of course, but where I work, were more a consulting architech that the architect that desigs the whole thing. We do what cusomers have visioned and inform what sucks in that context. We don't make the context , design or choose it.
Like construction company, we don' design the bulding we just build by the design and try to make it work well as possible. Within frameowork of time and expenses.
If the original idea sucks and can't work well, then it is so. It doesn't matter how good pianist you are, if acoustic sucks and composer did it all while drunk(besides being ungifted), you can't evoke miracles from absolutely nothing. You can only do best what those circumstances allow you to do.
Nobody knows the trouble I've seen, nobody knows has the trouble seen me, even I sometimes wonder why I write these line
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
So does ASP too. I have to agree with orignal poster of this thread.
I can understand why people adopt things like Tapestry and swear by it.
If you have enterprise leven solutions, you may have peculiar needs that aren't visible to us rest.
However, more I have done programming and web pages, more I think simplicity is best. More there are layers and neat tricks, more there is confusion and something that you have to debug.
Programming world is anyway filled with 'silver bullets' that people swear by. So far I've mostly seen good ideas to certain needs and lot of personal choices, but no overall silver bullet for everything that would justify adopting them all or just one of them.
If something helps making something better, there is usually catch somewhere, like extra time needed to learn it and/or more things to keep track of. And if you come back years later and system is complex, you may not remember how it works - especially if you have learned dozens of 'silver bullets' after that.
Many times simplest choice is just to do it by way you know best already.
My choice is a text editor or Eclipse, and do code by hand if it just is possiböe. Not much can go wrong, and if it does, I know where the fault is.
Nobody knows the trouble I've seen, nobody knows has the trouble seen me, even I sometimes wonder why I write these line
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?
Slashdot has jumped the shark.
You must be new around here. Either that, or you mean the fossilized bones of the shark that Slashdot jumped over and over years ago. At least it's still entertaining.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
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.
Yeah, I agree.
I can understand why people choose Java and do J2EE. I've studied J2EE and liked it.
But as I do work in LAMP enviroment, can't fathom why I should move to Java application servers in the web.
They're far too complex, many are still buggy and costs are high for then. Jsp doesn't offer much more than does PHP, infact I think to effectively use it, one needs to do lot more.
It's not that Java is hard or difficult, using it just create lot more work than using PHP. Unless you have some uber organization that needs lot of scalability and thread safety, then the sacrifice for java is not justified.
Nobody knows the trouble I've seen, nobody knows has the trouble seen me, even I sometimes wonder why I write these line
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.)
I'm agree that PHP will be the ease for web development. Java and ,Net are both too much complex and that becomes the issue for deployment. I would say both the complex framework are suitable for advance legacy systems, etc.
For fast, easy and wide deployment PHP will definitely be the best choice around. I'm wondering why people are not putting much attention in PHP kind of framework ?? There are some, but only bits and bites everywhere. And not getting much attention.
For RAD in PHP, I'm coming across something called Modules Driven Web-Based Application Development. Search through google but not much are focusing on this.
These are the same kinds of people who can tell the difference between normal high-quality copper cables and gold plated, revsered ionising, high-molecular partical charged, $10,000, copper audio cables.
If the Simple container is a valid Servlet container, then Tapestry will work fine within it. Tapestry's footprint is rather large, however. About 2 MB for the framework and its dependencies. That may compromise its use for embedded.
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
No... Java is going to change the world! Write once run slowly everywhere!
The main problem is, that almost everybody seems to think he has to program his own framework and then utterly fails in simplification or other areas instead of trying to improve the existing ones. Now we have the situation of around 100 frameworks or more, most of then do not bring anything new to the table but also most of them being only half baked. Only a handful really shine, that probably on the java side being
Wicket
Tapestry
and JSF
Struts, forget it it is a major pain in the lower backside and almost every line of code you save on the java side ends up in two lines of code on the xml side.
Depends on the domain, first the "will it" it has and has for a long period of time. The domain of those applications usually is in the areas which is bigger than the usual hackish php app. Java is very common in banking insurance company, fortune 500 etc... domains, you knoa what I mean. But for the average I need a quickly hacked page in two days page you wont find it that often.
Also with those languages probably nmost I learned php in 20 days and stuck with it people will get huge problems, you run into things you have not dreamed off probably. You will face the same problems all visual basic guys had when they suddenly had to move towards VB.net, you will have to learn the basics of algorithms and software engineering.
To make it short, PHP is good for small apps which you need to hack quick, where java frameworks usually due to the setup problems is dreadful, but once things become bigger java scales quite nicely both from a development point of view and from a speed point of view. Therefore it has become the choice for many bigger applications and companies where the I need something within a day problem does not apply to usually.
117 is the LOC for two examples. The php is closer to 66 lines if you remove the array's formatting and delete commments. Of course, the python is far more secure and readable.
J2EE Servers: You can get following without any costs: JBoss, Jonas, IBM Websphere Community Edition, Sun Glassfish, Apache Geronimo
Buggyness, not very buggy at all, most of them are very mature.
Complexity: Unfortunately yes it is there, but they cover a lot of domains, some of them have even integrated databases, security, clustering, messaging, remoting, webservices etc... you get this all out of the box
JSPs only are a small subdomain of J2EE JSP in fact ist the only thing very close to PHP and nowadays normally only used as a rendering technology for more extended stuff. Using plain JSP basically has been a no go for years now. Check out stuff like Tapestry, JSF etc... this is stuff people nowadays work with.
Book: Rapid Development.
Section: Classic mistakes
"There are no silver bullets"
Check. As long as I can build entire sites over the weekend, I'll keep developing with a framework that I know.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Well, Frameworks like tapestry are pretty server agnostic as well all they need is a valid servlet/jsp runner. The reason for this simply is that servlets/jsps have become the base technology for such frameworks, there is no use in providing your own servlet clone, the technology is mature and stable and dozends of implementations many of them free can be downloaded from the net. The last framework I have seen not doing this was around 2000 (and that one was utter cr***).
However, more I have done programming and web pages, more I think simplicity is best. More there are layers and neat tricks, more there is confusion and something that you have to debug.
Not really. There can be nothing as confusing as dozens of JSP/PHP pages with lots of repeated code and no central map of how the navigation is done.
Often structure gives clarity.
I've used PHP regularly for about the same amount of time. I've also used other languages, but I primarily use PHP. PHP does require you to be careful about program design. If you don't build a web app to scale properly then that's your fault in PHP. The language is not going to help you. However, most programs I've ever built don't require any sort of scalability other than playing nice with others. Even the ones that do need a lot of scalability can be done in PHP. You just have to be careful during the design phase. Sure a lot of things look like nails if you only have a hammer, but a lot of things really ARE nails.
I'm surprised no-one has mentioned Wicket in this thread. It is a component-based framework in the same mold as Tapestry but is a lot easier to work with...
Invoicing, Time Tracking, Reporting
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
...or maybe we can switch it to Java On Nails, Jon for short. People in the industry will be talking about how they "Used Jon to build this or that", and I will quietly sneak off and switch my name to "Jon" on my resume and watch the job offers pour in.
Next time please include "ultimate" ;)
I've actually been using Jetty as a development platform to test my code, but it's a bit of a memory hog. However, I note now that Jetty 6 is out and one of the goals was to reduce the footprint and dependancies apparently. I'll be checking the update out, thanks for the suggestion.
Hehe,
... if you use it because it simplyfies something for you, of course you have to configure it.
you only add and use them if you want to use them.
A standard Java Web Application does not need hibernate/spring
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Relying on constant diligence and universal competence IS a gaping security hole. A good web environment should rely upon the fact that all people are idiots all of the time.
No... Java is going to change the world! Write once run slowly everywhere!
;-)
Not everywhere: "You acknowledge that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility." Good thing, too, or it might indeed "change the world"!
Attention zealots and haters: 00100 00100
It runs on the general-purpose cross-platform runtime the industry has chosen.
Make Zope/Plone run on any standard JVM and that might change.
Ad to what?
Either it's an ad to DeveloperWorks, which is fine for they run interresting articles about most languages and frameworks and get linked everywhere all the time.
Or it's an ad to Tapestry, which is an OSS framework...
Wait, aren't ads supposed to generate some kind of revenu or something?
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Well, Java is nice indeed, but it's not necessary. Anything you can do with Java, you can do with Brainfuck. Just wanted toi make it clear that your statement is stupid.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Two comments on your post:
If you assume that all Tapestry is doing is routing requests and outputting HTML, you are missing the forrest for the trees. To be honest, I think most web application development is primarily about state management (transient state used for one request, persistent state used across requests, stored on the server or on the client). These are more areas where developers are used to slaving away, but a real framework is quite capable of handling it, and handling it better than the developer can (at a certain scale of complexity). So, as long as you are happy to try and manage everything in terms of HttpServletRequest and HttpSession attributes, and endless code to pick apart query parameters, and a bunch of other limitations, you can get by with something simple. I tend to think of Tapestry, not as more complex, but as more complete.
Second, there is an inherent and invalid assumption in your statement that Tapestry is not scalable, when in fact, it is very scalable not just in terms of concurrent users, but scalable in many dimensions: scalable in terms of number of pages, of number (and type) of developers, in the complexity of pages. What's important is that as your application does grow more complicated, your approach never has to change ... in effect, Tapestry is built for the worst case: highly dynamic pages, complex forms, multiple forms per page, complex client-side JavaScript, etc. A major portion of what Tapestry does is fundamentally about naming things, particularily form control element ids, and JavaScript functions and fields, to avoid naming conflicts. But even in terms of basic scalability, Tapestry uses a pooling mechanism around its page objects to support effecient, concurrent access by restricting non-threadsafe objects (the pages) to individual requests (and, thus, individual threads).
So, what you get is an object oriented programming model (hey! look! objects with methods and properties!) in a highly multithreaded environment without having any concerns about multiple threads. The pooling and typesafety is baked into the framework, not the code you write. Further, you get to build a servlet application without ever seeing the servlet API (unless you really want to).
So, yes, there's a lot of moving parts in Tapestry, but they are all there for a purpose. I personally find Tapestry useful even for a single-page application ... and I wouldn't want to use anything else when I'm working on an application with dozens or hundreds (even thousands) of pages and components.
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
Sorry I didn't reply sooner. I was troubleshooting an XML file so I could persist my data.
"He was a wise man who invented beer." - Plato