Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Software

Tapestry Making Web Development a Breeze? 268

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."
This discussion has been archived. No new comments can be posted.

Tapestry Making Web Development a Breeze?

Comments Filter:
  • by Escherial ( 806342 ) on Saturday January 07, 2006 @07:29PM (#14418658) Homepage
    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.
    • by evn ( 686927 ) on Saturday January 07, 2006 @07:43PM (#14418710)

      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").

      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.

      • I'm in the process of learning the language and framework and, yes, there is much joy. Especially if you come from ASP.NET and PHP.
      • ...domain specific languages, duck-typing, or any of the other things that make rails really productive...

        What the Rails crowd seem to forget is that the issue of whether domain specific languages and duck typing really lead to long-term productivity has been a matter of hot debate for decades. It is all to easy to state that they are productive as is this was some established and universally acknowleged fact. It isn't. They certainly happen to be fashionable at the moment, as they were 20 years ago.
      • I'm one of those people that gave RoR a gander and didn't really care for it. Most people looking at rails, I suspect, are already experienced with other frameworks... yet all the tutorials focus on is how easy it is to slap together cookie cutter database frontends in 10 minutes and how easy the scaffolding makes life (at least when I tried months ago). I've been doing web apps for a while now... showing me how easy it is to build a recipe database is really not very impressive. My suggestion would be that
    • New developers need to become familiar with frameworks like this in order to become exposed to to the (large, powerful) toolset that the Java world provides. When I started Java development these things didn't exist and I had to walk to school 5 miles each way barefoot in the snow uphill in both directions everyday. If you are mentoring young developers these frameworks provide a good kicking off point for design and architecture education.

      And lets be realistic - not using a framework isn't going to cure la
    • 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").
      Do you realize scaffolding is less than 1% of what Rails is about? To cite Rails as a tailored cookie-cutter system isn't some great insight on your part, it's rather a profession of ignorance.
    • by Anonymous Coward
      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 t
    • 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?

      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 int

      • by misleb ( 129952 ) on Saturday January 07, 2006 @09:36PM (#14419149)
        Bulletin: Easy programs are easy to write. Hard programs are hard to write.

        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

        • 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...
          • 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 migh
      • this is a way too simplistic a view. language does matter, and on many levels.

        when you study programming, it shapes your mind. when building software, it shapes the universe in which you model your target system. not to mention realities of software development in real life (here on earth, may be on your planet its different). you have to train people, you have to get people to work together. and different languages and environments have different devices to support (or, frankly, to discourage) these things
      • That's because text editors can cut/paste, and run macros you can code once to make them smack out templates for you.

        A typical "text editor" might have cut and paste, but it sure as heck doesn't have macros in it. When you start adding that in, you're not terribly far away from being either an IDE or a "Word Processor".

    • I wouldn't worry about it. If these folks are to be competitive, they will manage to learn the material themselves, or find education in it.

      What I WOULD worry about is management cracking out on every new buzzword that comes along. Perhaps you can't get a project done using only "buzzword X." That I worry about, but, interestingly, introducing new buzzwords really doesn't change the situation.

      Relax. Why do you care what a bunch of web developers are doing anyway? If they have their fun with whatever to
    • 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").

      And what is wrong with a "database browser" web application? If you have a perfectly good database model that you want people to interact with, why not use a database oriented framework? Why should anyone have to reinvent a framework every time they want to write a database driven web application? I'll tell you

      • And what is wrong with a "database browser" web application? If you have a perfectly good database model that you want people to interact with, why not use a database oriented framework? Why should anyone have to reinvent a framework every time they want to write a database driven web application? I'll tell you what, going from brain dead PHP to Rails was a huge boost in productivity.

        Because when you get above a certain size and complexity of application you soon realise that a web application can end up as
        • 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.

          -matthew
          • by Decaff ( 42676 ) on Saturday January 07, 2006 @10:08PM (#14419243)
            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?
    • If you think :scaffold is all that Ruby on Rails is, you haven't used it enough.

      And anyone who works in web development is that the vast majority of applications are CRUD. Anything that keeps me from having to duplicate all the hoops I have to jump through to get CRUD working on PHP or ASP.NET is wonderful.

    • by melquiades ( 314628 ) on Saturday January 07, 2006 @09:37PM (#14419152) Homepage
      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.
    • No doubt people said the same thing about the development of high-level languages. I know Plato said it about writing (which he thought would damage people's ability to remember). These things don't prevent the gifted from learning or working, they just let average people do some kinds of work they couldn't do without them.
  • Written backwards (Score:5, Insightful)

    by Anonymous Coward on Saturday January 07, 2006 @07:46PM (#14418721)
    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.
  • pfft, web based tapestry making [adgame-wonderland.de] has been around for ages.
  • by Anonymous Coward
    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/ [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/ [squeak.org], is open source and...
    Wait is not sponsore
    • Why other frameworks like Seaside http://www.seaside.st/ [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/ [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


      No, it is because systems like Squeak, no matter how technically wonderful it is (and it i
    • Sorry to jump the gun here, but I had a quick check on seaside, and I must say, a controller->ui on the code level scripting framework does not make it. I have been programming with such a thin in java for a while now (being forced too), while it is excellent in the areas of having one standardized domain of problems, mainly backend applications which do not require excessive ui layout and excessive ui changing, it simply does not make it in normal day to day situations, where usually a layout comes from
  • by daniel.norton ( 937157 ) on Saturday January 07, 2006 @08:26PM (#14418863)
    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 [cleverlance.com]). 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.
  • Don't be put off (Score:4, Insightful)

    by Budenny ( 888916 ) on Saturday January 07, 2006 @08:42PM (#14418937)
    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.
  • by Bogtha ( 906264 ) on Saturday January 07, 2006 @08:51PM (#14418970)

    I just finished reading an interesting comparison [pythonmac.org] 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:

    • 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.

    That's to implement the same web service.

    • by Decaff ( 42676 ) on Saturday January 07, 2006 @09:13PM (#14419061)

              * 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 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
    • Huh, the python and PHP versions don't use SQL? Then why does Java?
    • by melquiades ( 314628 ) on Saturday January 07, 2006 @09:45PM (#14419168) Homepage
      ...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."
    • by AlXtreme ( 223728 ) on Saturday January 07, 2006 @09:52PM (#14419194) Homepage Journal
      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!

    • 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.

      Java based web apps take longer to code in my experience. I dislike php and haven't found time to play with ruby on ra
    • 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 expan
    • 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
  • by CaroKann ( 795685 ) on Saturday January 07, 2006 @08:56PM (#14418980)
    In my opinion, the appearance of yet another framework to help alleviate HTML development is a symptom of the flawed HTML web page application paradigm. Every time I grit my teeth over the tedious complexities and limitations involved in developing an ordinary, half decent web page, I long for the days of Visual Basic, or even MFC. Does anybody even develop GUI widgets anymore? It seems like to me that, after everything became webified, we stepped into some kind of GUI dark age, and we can't seem to emerge from it.

    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.

    • In my opinion, the appearance of yet another framework ...

      Just because a new article shows up it does not mean a new framework shows up.

      Tapestry is an old one.

      angel'o'sphere
    • I agree the whole web development paradigm is utterly broken and giving this idiocy entirely the boots and unlearning the people who learned this dreck will take another 10 years. Fortunatly there are at least some frameworks which try to brigde the gap between having a decent ui programming model on top of the broken paradigm. Tapestry is one of them html.net is the other JSF being the third.
      But most frameworks try to go along the route of plain actions and boilerplate mvc on top of it without any event
  • TANSTAAFL (Score:5, Insightful)

    by angusmci ( 850386 ) on Saturday January 07, 2006 @09:16PM (#14419069) Homepage

    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.

    • by melquiades ( 314628 ) on Sunday January 08, 2006 @01:18AM (#14419936) Homepage
      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?
  • by account_deleted ( 4530225 ) on Saturday January 07, 2006 @10:14PM (#14419262)
    Comment removed based on user account deletion
  • There will always be a need for developers. The lack of creative flexability that these types of systems offer will be their ultimate downfall.
  • by acomj ( 20611 ) on Sunday January 08, 2006 @12:55AM (#14419841) Homepage
    Sun's java studio creator is now free. I'm not sure which "framework" if any it uses but it seems a quick and
    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/jscre ator/index.jsp [sun.com]
    http://developers.sun.com/prodtech/javatools/jscre [sun.com] ator/reference/quicktour/2/flash/index.html
  • 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.

"When the going gets tough, the tough get empirical." -- Jon Carroll

Working...