Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Java Frameworks and Components 153

Posted by timothy from the tying-things-together dept.
Simon P. Chappell writes "Life is busy enough without writing your own infrastructure code. With all of the high-quality frameworks available today, it's no longer necessary to even think about writing low-level code (except as a technical exercise, or to express your inner geek :-) Our problem today, is to review and select the best available framework for our needs. This is a non-trivial task, but help is at hand with Java Frameworks and Components by Michael Nash." Read on for the rest of Chappell's review.
Java Frameworks and Components: Accelerate Your Web Application Development
author Michael Nash
pages 477 (14 page index)
publisher Cambridge University Press
rating 9
reviewer Simon P. Chappell
ISBN 0521520592
summary A tour de force! With only one quibble, this is the definitive work on Web Application Frameworks.

Overview

This book is a superb exploration of the current state of the web application development framework market. Both commercial and open-source/free frameworks are examined in detail.

The book works through a logical progression, starting with a discussion of what a framework is (and, of course, what it isn't) before moving on to an examination of the benefits that they bring to development efforts. The meat of the book is in the next couple of chapters where a framework (no pun intended) is explored to select and compare frameworks. A list of current frameworks is given, each being described, with strengths and weaknesses highlighted.

The trailing chapters cover aspects of development that are affected by the use of frameworks, including the obvious ones like IDE support and methodologies.

What's To Like

The aspect that most impressed me was the depth of research that has obviously gone into this book. I think most of us know that frameworks are good, and a reasonable number of us could list several reasons why they are good, but I suspect that very few of us could generate such a comprehensive and cogent rationale for using a framework.

The information density in this book is quite high. Normally, I read technical books quite quickly, but this one took a while, because every good point prompted much thought and consideration. This was impressive to me after seeing so many books coming to the market that have simplification as their rationale for existence. The selection of an appropriate framework for web application development is not a simple task and this book takes it very seriously.

While non-free frameworks might be a non-issue for some of the Slashdot crowd, those of us working in corporate I.S. have to be very aware of the differences and our local management's attitudes concerning it. The book does come out strongly in favour of open-source and free software, but does not let this bind the discussion in any way. Commercial and free software are judged equally and fairly throughout.

Pragmatic is a much over-used word these days, but I would describe this book as pragmatic. The advice given concerning framework selection, urged people to consider many factors, including existing frameworks used in-house, the type of project, the degree of accordance between the services provided by the framework and the requirements for the system being written. I have seen many a framework selected because it was buzzword compliant, so this advice was a refreshing change.

What's To Consider

After enjoying the book, to reach the case studies and be disappointed was, well, disappointing. The case studies seemed rushed and lacking in substance. The idea of comparing and contrasting the four leading frameworks to solve the same problem was a good one, but somehow it didn't quite come off. The Struts case study got to me the most: I have conniptions everytime I see business logic in actions! Perhaps the case studies could be dropped in a future edition?

Summary

A tour de force! With only one quibble, this is the definitive work on Web application frameworks.

Table Of Contents

1. Components and Application Frameworks
2. Components: The Future of Web-Application Development
3. Application Frameworks: What Do They Provide and What Are the Benefits?
4. Choosing an Application Framework
5. A Catalog of Application Frameworks
6. Comparing Frameworks
7. Open Source and Components/Frameworks
8. Development Methodologies and Design Patterns
9. Integrated Development Environments
10. Strategies for Using Frameworks: Best Practices
11. Conclusions: The Future of Frameworks and Components
Appendix. Case Studies

You can purchase Java Frameworks and Components: Accelerate Your Web Application Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Java Frameworks and Components More

Java Frameworks and Components

Comments Filter:

  • Case Studies (Score:5, Insightful)

    by krulgar ( 250929 ) on Tuesday November 25, 2003 @02:14PM (#7560093) Homepage
    Case Studies (as in this case) always seem to come at the end of the book. If they were really analyzed they'd be earlier. Too often this is the author's response to the publisher's request for 80 more pages.

  • aren't? (Score:3, Interesting)

    by dance2die ( 596340 ) on Tuesday November 25, 2003 @02:16PM (#7560120) Journal
    Arent' there as many frameworks as there are coffee types in Starbucks? I wonder which java framework i woudl like to choose.. IT's a daunting task for me already to pick a right flavor @ coffee shop... :)
    • I was just reading about that dillemma here:

      http://otn.oracle.com/oramag/oracle/02-nov/o62odev _java.html [oracle.com]

      If you ask me, the whole thing is retarded. Whenever you get these high level abstract frameworks, they imply limitation and slowness, both in running and writing. (Examine Zope as a perfect non-java example.) People forget that learning new frameworks takes lots of time, time that could have been spent just writing code. They also limit what you can do for everything they give half the time.
      I us
  • (Raises hand)

    I think I understand the term, but does that mean it's a given that any application is built around a "framework"?

    All well-constructed software is sliced into coherently-discrete layers that are solved as individual problems, but I believe the "framework" concept is largely a commercial concept designed by certain vendors to enable them to sell large, complex toolkits.

    Are we not in danger of taking this commercial model and turning it into dogma, in which your application shall be built around a framework and the only choice is "which one?"

    • Re:WTF is "infrastructure code"? (Score:5, Informative)

      by nehril ( 115874 ) on Tuesday November 25, 2003 @02:50PM (#7560486)
      all applications use frameworks. the only question is where do you get your framework: do you code it yourself or use someone elses?

      lots of apps need to validate form input, connect to a database, retrieve data and save settings. these are generic "framework" tasks that apply across a wide range of applications. You start with these base foundations (either you roll your own or use someone elses), and decorate it with your particular business needs.

      Frameworks like Struts for web apps include much of the stuff you would do yourself anyway: authentication, validation, form repopulation, session management. since lots of geeks/nerds get together to create these frameworks they are often more complete than something you would whip up yourself.

      Since they do stuff you were going to do anyway, they can save tons of development time. that's why it's an important topic to be educated about. they are not just "make money commercial concepts."
      • Since they do stuff you were going to do anyway, they can save tons of development time.

        This is the ideal, but it doesn't always work out in practice. From what I've seen in the real world, a common thing is to adopt a framework, like Struts or J2EE, then think it isn't necessary to really study it and learn its nuances, then look confused when the application breaks and is very hard to debug due to the two or three extra layers of software. The result is a bunch of programmers pointing fingers until en

        • Those "extra" layers of software are arguably layers that you should create yourself anyway, just to separate out presentation logic, business logic, etc. If it breaks, ideally you will have the source code, so no big deal. Either way, you should have support in the form of a community or a business. Had you rolled it all yourself, you'd be on your own.
          Personally, I'd rather see someone I put to task working on solving the problem than writing and debugging new wrappers for everything they way they think
  • Who writes the frameworks? HAL 9000? Nanomachines?

  • Who are you? (Score:5, Interesting)

    by Sean80 ( 567340 ) on Tuesday November 25, 2003 @02:21PM (#7560156)
    I've said it once, and I'll say it again. Who are you, reviewer? Are you connected to the author or the publisher? Do you have any financial interest in this review?

    At least try to provide a disclaimer. Otherwise, an excellent review of a technical book published on probably the largest technical web site on the internet. Smells like fish, tastes like fish to me.

    My 2c.

    • Re:Who are you? (Score:3, Informative)

      by wideBlueSkies ( 618979 )
      >>I've said it once, and I'll say it again. Who are you, reviewer?

      He's some dude who works for Land's End. [google.com]

      wbs.

    • Re:Who are you? (Score:5, Informative)

      by The Masked Rat Fink ( 68826 ) on Tuesday November 25, 2003 @05:18PM (#7562134) Homepage
      Good question.

      I am the author and I appologise for forgetting to put a little something about me in the review. My excuse is that I'm too humble, but who knows if you'll buy that? ;-)

      I am a Java developer with Lands' End. In fact, I was the first Java developer that LE hired, and I've been with the company five years now. I have worked with Java since version 1.0 and was also responsible for the first Java program written at my previous employer (CUNA Mutual Group ... Go Credit Unions! :-)

      I have a slight relationship with the publishing houses, in so far as they send me books. I have no connection to the authors. I get to keep the book, but there is no payment for these reviews. I am highly opinionated, so if I say that I like a book, then that's the straight dope. Check out my personal website if you want proof of my willingness to express opinions (http://www.simonpeter.com/)

      Hope this helps, and I'll put in a bio next time.

      Simon

  • Why not write your own Framework? (Score:5, Interesting)

    by Guru1 ( 521726 ) on Tuesday November 25, 2003 @02:22PM (#7560164)
    Simply put, our group wrote our own struts type framework. This was around 4 years ago when struts wasn't quite as hyped, and we wanted something that did exactly what we wanted, without extra baggage or cost. Four members in our group, it took us around a week to write the basic components.

    Other groups (sitting a few feet away from us), have gone through a couple framework tools, ending up with struts.

    I really don't see a difference in either approach. So many times writing your own tools is frowned upon, but when you're talking about small scale projects, why not? Do you really need every feature of struts to display a fairly simple website? A few forms, polls, etc.. why install such a massive package?

    For my home machine, I wanted a couple forms, a photo album, and fairly simple navigation. I wrote it in a night. It would have taken me just as long to download the tools, install them, and set them up.

    I think the problem is that it's a very "in thing" to use the latest tools. The technology lead for the other team was pushing for one open source solution before, then was pushing for struts, now is pushing for some other "cool" tool. I would rather focus on writing for what is needed, rather than for what is a cool solution.
    • I completely agree... Many frameworks are totally bloated and/or buggy... An inhouse framework will meet needs more closely, and will always be more efficient than a generic framework... When performance is important, and full control desired, an inhouse framework is the way to go...

      You'll hear people argue that using an open source framework (and most are) will allow you to modify the code, but once you down the path of making changes, forget about upgrading as new versions are released...

      My 2 cents

    • right - get the job done and get it done right. However, a framework is really useful on very large projects, when you can override classes and make good use of code reuse. This is helpful when you have your more skilled developers doing a lot of the interaction between the framework and the customizations to it to fit your specific needs. Then the more junior programmers can simply tie everything together at that point.

    • Re:Why not write your own Framework? (Score:2, Interesting)

      by Anonymous Coward
      In general it is a best practice within all of engineering to reuse what is already there. It takes time to design, develop, test, and maintain a custom framework. It may start out as simple but over time the chances are that it will grow. As it grows the upkeep will grow. By using a framework that is already highly regarded by the industry you save yourself all of those costs as well as benefit from using a proven technology. I am not talking about bleeding edge frameworks that are not standardized li
    • I used PHP extensively for a number of years and finally wrote my own framework. In the end it turned out to be very much like some of the Java frameworks out there.

      IMHO the good parts about PHP are also the bad parts. ie, * you don't have to say what type a variable is, but that means you can't specify a type of parameter to a function. * you don't have to specify scope, but then you can't protect functions that should be private etc.

      I looked at a lot of Java code for ideas on what I could do with PHP to
    • I wonder about this sort of a solution in the long term though? The team that I work for wrote their own framework a while back and since that time has grown and had signficant turnover. Sure everything is fine when the original members of the team are there that have inside out knowledge of the framework that they wrote, but when they leave then you tend to lose a lot of that knowledge. This can be solved by good documentation, but at least in our project that didn't happen and I can't see it happening in

    • Re:Why not write your own Framework? (Score:5, Interesting)

      by enjo13 ( 444114 ) on Tuesday November 25, 2003 @02:56PM (#7560558) Homepage
      While you qualify this 'especially for small projects', I feel that all projects (big or small) benefit from standard underpinnings when they are available. One of the absolute BIGGEST reasons to standardize on a open and free framework like Struts is a business buzzword known as 'knowledge management.'

      It is MUCH easier to find a programmer familiar with Struts than it is to find one familiar with your framework. When you leave the company, move onto other projects, or (god/allah/diety of your choice forbid) are hit by a bus your proprietary framework now must be maintained by someone else. If you had used a standard framework to do the same thing, then you can easily go out and find a programmer who can more easily step in and fill that role.

      There are, of course, lots of other benefits. When your framework has a bug, it requires your time to find and fix it. One open, free frameworks it's often fixed before you even know about it. When you have lots of developers working together on a mission critical piece (the framework), then your application benefits with only a small effort from you. The whole is MUCH greater than the sum of it's parts in this case.

      The only caveat to this is knowing when a tool TRULY meets your needs. I'm a PalmOS C++ programmer (a rare beast:) ) and while there are a couple of nice C++ frameworks out there, neither begins to address the level of abstraction that I desired. I could have used them, but would have spent more time fighting the framework than I would from enjoying it's benefits. So I rolled my own. If there was a framework that truly met the needs of my application, I would have used it in a heartbeat. It sounds like the problem for your 'other groups' isn't the frameworks, but their inability to accurately understand how the framework fits into their product.
      • I agree that writing your own framework severely decreases the "truck number" of the project. My current project is pretty much screwed if I get hit by a bus. Right now, I consider the benefits we're getting out of having 'rolled our own' to outweigh that risk. I do have the best of intentions of putting more effort towards documentation, commenting, etc to try to make the framework survive my tenure here...

        I think the risk of established frameworks, the trade-off, is that they are not going to be optim
        • I do have the best of intentions of putting more effort towards documentation, commenting, etc

          How's that road to hell coming?
          • I find the road to be a pretty slippery slope for the most part :-).

            In my defense, I do revisit things pretty much every day and comment out *something* or clarify the code better. In my current situation, that's the appropriate use of time, because I only have 2 other developers relying on this code base, and they already know it pretty well. I try not to envision the "getting hit by a truck scenario", since I'm a firm believer that you always get exactly what your thoughts dwell on (*)

            (*) except for t
      • One open, free frameworks it's often fixed before you even know about it.

        It should be stressed that frameworks are most helpful when they are open-sourced. Fixing the bug first and, then, notifying the maintainers later is something that really saved my ass once.

      • One open, free frameworks it's often fixed before you even know about it.

        Only if you're willing to stay on the bleeding edge.

        I am a developer at one of the web's busiest sites. If we were to incorporate a framework, it wouldn't be very long before our unique requirements (some legacy-driven, some traffic-driven) would require a code fork.
        There are many reasons why a framework is a useful addition to the codebase and just as many reasons why it is not.
    • I have also written my own framework. Actually, I've "written" it at least 3 times -- once in Perl, once in Java, once (again) in Java once I understood tag libraries and JSP's better. It was an evolution of concepts and best practices in Web programming borne out of my experience in the field (I think I wrote my first web app in 1995?).

      I wrote my framework because at the time, there wasn't anything out there that was decent and fit my thoughts and opinions about "how it should be done". So far, it's wo
    • I agree fully, I've done the same though I prefer to call it a "library". A framework sounds so pretentious.

      Our library (it was "mine" once but now it is a shared effort of about 4 developers in a group of 30) does about the same as struts, and also contains custom tags. It is not configured by ugly xml files though, but 100% based and focussed on JDBC.

      The library itself was a relatively small effort, and it pays back because it is totally tailored to our needs. The project is large enough to justify the

    • Re:Why not write your own Framework? (Score:4, Informative)

      by MSBob ( 307239 ) on Tuesday November 25, 2003 @03:42PM (#7561103)
      Our company did the same thing. They wrote their own frameworks to replace struts and their own O/R mapping layer.

      It was one of the overlooked disasters.

      Things looked pretty good for the first year or so when the requirements were straightforward and the persistence mapping quite simple. As the product grew the frameworks we built got very complicated very quickly and everything we built was in some form available in other products. Maybe there wasn't a one for one feature match but I think the small discrepancies absolutely did not justify the effort spent on building your own application framework.

      Why anyone would build a persistence layer when Toplink and Hibernate are both excellent tools which will almost certainly outperform homegrown solutions.

      Same with struts. We built our own struts-like framework with our own tag libraries and our own templating engine. Now we have to have people dedicated to maintaining that stuff all the time and at least keeping pace with the popular frameworks.

    • On the one hand, depending of course on the project, I am all for writing a framework to support the application structure required.

      On the other hand, it can have MAJOR downsides. If the technology choice is wrong, or if the dvelopers are not quite up to the task (despite protestations to the contrary), things can go quite horrible.

      At the company I work for, a couple of guys were given the job of building a development framework for building ALL internal infrastructure applications on. For some, utterly u
    • I agree. Sometimes it takes more time to study the ins and outs of an existing framework than to write a skinnied-down one for yourself.

  • Rolling my own... (Score:1, Interesting)

    by Anonymous Coward
    Am I the only one who thinks that sometimes its simpler, not to mention more fun, to write my own low-level/framework code? Before you flame me, I DO understand the value of using a framework (reuse, time, integration, other developers, blahdiblah). When you write your own framework, you get to be Da Man.

    • Re:Rolling my own... (Score:1, Funny)

      by Anonymous Coward
      I prefer to roll my own. Who knows what kind of shit someone else might stick in behind closed dorrs. You don't wnat to get halfway through your joint before realizing it's laced with sawdust. or pcp.


      I smoke GNU/Pot that I roll myself.

    • If you have the time and interest to do it, it'll always be the better choice. The problem is that generally (unless you're some megacorporation) you don't have the time, manpower, or interest to invest in writing your own framework, at least when you see the amount of existing tools that are out there already. It's also cheaper to user a ready-made one.

      So I wouldn't say it was 'simpler,' but definantly more fun. :)

    • Re:Rolling my own... (Score:4, Insightful)

      by Garg ( 35772 ) on Tuesday November 25, 2003 @08:55PM (#7564290) Homepage
      Yep, you get to be Da Man, all right.

      You get to be Da Man who gets called at 3am when one little thing you forgot brings the whole shebang down. You get to be Da Man who gets to enhance it for every little niggling request from your fellow coders. You get to be Da Man who has fingers pointed at him first, then find out later somebody's app didn't follow your rules. You get to be Da Man who meticulously documents it, so they know those rules.

      You get to be Da Man who can't take vacation or call in sick.

      I gave up my desire to be Da Man some time ago.

      Garg

  • Did you actually read the book? (Score:4, Insightful)

    by ViolentGreen ( 704134 ) on Tuesday November 25, 2003 @02:27PM (#7560217)
    If so I can't really tell. The review seems pretty empty and doesn't really contain any hard info that couldn't be found on amazon.com.

    That being said. Java's frameworks tend to be very high quality and easy to work with in my experience.

  • Useless (Score:5, Interesting)

    by blamanj ( 253811 ) on Tuesday November 25, 2003 @02:28PM (#7560228)
    Excuse me, but what frameworks are compared and covered?

    Are we talking GUI frameworks, JSP Engines, Web application frameworks, what?

    This "review" told me nothing.
    • I concur. Is this a book about _how_ to evaluate frameworks, or does it actually evaluate some. The review is sorely lacking.

    • Which frameworks are covered (Score:4, Informative)

      by mjglobal ( 559663 ) <mnash@jglobal.com> on Tuesday November 25, 2003 @06:33PM (#7563000) Homepage
      The book covers Java frameworks, primarily web-application frameworks, and discusses how to compare in general, and goes into detail on:

      Avalon, Cocoon, Expresso, Arch4j,
      ArsDigita ACSJ, Turbine,
      Wakesoft Architecture Server, Niggle
      Systinet's WASP, realMethods, Brazil
      OpenSymphony,
      JSF (not quite a framework per se, but covered),
      Struts, Maverick, Scope, WebMacro,
      Velocity, Tapestry, Barracuda, HyperQbs,
      Tea, Freemarker, Echo, Xerces, Xalan,
      Axis, Slide, Roaming Wireless Framework,
      JADE, Openadaptor, JUnit, Anteater,
      Jetspeed, OpenPortal, uPortal, Simper,
      Object/Relational Bridge, Castor,
      jRelational, Batik and Keel,
      along with mentioning more briefly a lot of others.

      (disclosure: I'm the author - of the book, not the review - so opinions may be biased :-)

      Mike
      • Thanks, it would have been nice to see that list in the review.

        I'm curious though, why you lump everything together under the word 'framework.' To me, framework implies a particular programming model that must be maintained. So JUnit is indeed a framework, though it doesn't at all compare directly with Struts, a framework with a completely different purpose. When I looked at the table of contents, I expected to see some sort of classification scheme.

        And things like Xerces I wouldn't class as a framewor
        • You're quite right that "framework" is a broad (and sometimes misused) term. I go into that in some detail in the book, and the frameworks reviewed are divided up by category to make it clearer (e.g. whole-application frameworks, persistence frameworks, presentation/UI framworks, etc)

          I thought Xerces was just a tool/API as well at first, but with bit of digging I found it actually is more of a framework, with pluggable implementations, a component structure, several different APIs, etc. That's why I though

  • framework, insfrastructure and other buzz words (Score:4, Insightful)

    by GillBates0 ( 664202 ) on Tuesday November 25, 2003 @02:39PM (#7560352) Homepage Journal
    Somehow, whenever I see a book (or review thereof) with a lot of words like infrastructure, framework,case study, component, in-house,my buzz-word radar goes up. I have given up reading many a book lately, just because I hate the wordiness that goes in to describing the concepts/theory.

    And lately, I have started looking at Java as a corporate-hep buzzword too, not to mention .NET, and a hoarde of other ones.

    Whatever happened to the concise, well-written, to the point books of a few years ago. Kernigan/Ritchie's C book comes to mind, though it was a C Reference Manual.

    • Whatever happened to the concise, well-written, to the point books of a few years ago. Kernigan/Ritchie's C book comes to mind

      Amen, brother. I spend as much time sifting through useless books as I do reading useful ones these days. K&R was wonderfully direct. Even the nutshell books aren't that direct anymore.

      Devon

  • Hard to keep track (Score:5, Insightful)

    by Timesprout ( 579035 ) on Tuesday November 25, 2003 @02:42PM (#7560385)
    Its almost impossible to keep track of all the frameworks that have sprung up around Java. It seems hardly a day goes by by without someone announcing either a new framework to address issues the rest of us were not aware existed or a new release of release of one of the plethora in existence.

    I find myself in a rather ironic position now. A few years ago I was a strong proponent of frameworks. I saw no reason why essentially the same code should be rehashed slightly differently when a framework could be made of the core material and the rest customised as required. Now I have to press the pause button when a framework is put forward to determine if it suits our requirements or is complete overkill for what we need or forces us into an excessively complex architecture to facilitate it.

    While still in favour of frameworks I believe you can have too much of a good thing. I think many frameworks available today ignore the "frame" part of the concept and actually try and fill in all the code for you.
    • I agree totally. The java market is littered with frameworks with cool names, but they are all generally overkill that cost a lot of money. You need something to do A, and the product does A, B, C, D, E and a little bit of F. Well, are you going to pay for that, or roll your own to do A and be done with it.

      Aside from the app server, we never used all these fancy frameworks.

  • Standard frameworks not always the answer... (Score:1, Interesting)

    by Anonymous Coward
    Because you've got to spend a lot of time learning them. We looked at a bunch of frameworks (Avalon, Klim, and some others) and felt the amount of time needed to learn the framework was about the time it would take us to implement our own (we didn't need many features, just component loading and common db and log access).

    So we rolled our own. Since java has interfaces, built in rpc, threading, and db-independant DB accesss, and most IDEs support some refactoring, it was pretty easy. Except for that cla

  • Traditional frameworks are fine - but the productivity benefits come at a cost - flexibility.

    What I've found that often works far better is:

    - divide system into major business-oriented (vertical) sub-systems (assemblies, whatever). Examples of these sub-sytems would include 'party', 'inventory', 'order', etc.

    - if possible build these sub-systems using highly adaptable code or based upon well-conceived patterns

    - glue the assembles together using a highly productive / adaptable language - python, etc.

    If

  • Low Level Java (Score:5, Funny)

    by jetkust ( 596906 ) on Tuesday November 25, 2003 @02:57PM (#7560574)
    With all of the high-quality frameworks available today, it's no longer necessary to even think about writing low-level code.

    And all this time i've been writing all my bytecode with a hex editor, like a sucker.
    • it's no longer necessary to even think about writing low-level code.

      Well, what's even funnier is that this is pretty much the exact same thing people said about Fortran and, then, C.

      When people say things like "finally you don't need to write low level code," they are really advertising how ignorant they are about software engineering and history.

      • I can't stand hearing people say this as well...

        Inspite of all these great frameworks that are poping up everywhere... You still need to understand how the code works inorder to utilize it properly.

  • Until you have to do something that the framework assumes you weren't going to do. Something like... adding a netscape-specific form tag element to your struts form to prevent the Netscape password manager from popping up. Then you can fight your way through 5 levels of management buerocracy in order to implement a new tag library just to keep your QA people and your users from getting confused. In other words, what should be a simple one-line change in a text file becomes essentially impossible.

    I'll say

    • Amen, brother.

      While I don't quite agree with If your web-app is so complex as to need a framework, your web-app probably sucks, since even a simple bank-balance application can benefit from a good framework.

      However, I'm afraid that the backlash may take much longer to arrive (and we'll be stuck coding in the ghastly web-app universe for aome time). The reason is that kludge after kludge will be layered on top of the browser (Sparkle, anyone [slashdot.org]) as an attempt to "get by".
    • Kay, couple of nits to pick here. First off, I think you meant HTTP protocol, not HTML. HTTP is perfect for what it was designed for. That is shuttling documents back and forth to between clients and a server. It is very simple to understand and implement.

      Second, what's wrong with Javascript? It is very useful in a web app. Field validation, UI enhancement, etc.

      Third, I think you are ignoring all of the benefits of deploying a web app VS a standalone application. Such as support (much simpler IMH
      • Yeah I meant HTTP, my bad.

        JavaScript would be great if you could count on it being implemented correctly on every browser. That goes for a lot of browser features. Browsers were never intended for the UI work they're not being used for. If I have to implement a heaping helping of UI code in JavaScript, why not just go back to C and do it using a protocol where I can actually maintain the state of my application from moment to moment?

        I am not ignoring all the benefits of deploying a web app Vs. a standal

        • Yeah, the javascript support situation blows ass. So does CSS support *cough*IE!!*cough*. And it is true that you will have to set limits on what browsers people can use, but I still think it is easier to deal with the support with a web app. For one thing, all the logs are right in front of me. It's really easy to grep the access logs for the users login name and get any errors associated with them. For another thing, webapps only have to worry about a handful of browsers that matter (IE, Safari, Moz,
      • A very good point. I just want to add one more advantage: data transfer. It is a heck of a lot easier in a lot of cases to deploy an app on a pre-existing web server and have users go to a web page than try to fight your way through a corporate IT department to get ports opened up for a custom app, especially now that everyone is afraid of RPC.

      • Re:Yeah Frameworks are Great (Score:5, Insightful)

        by j3110 ( 193209 ) <samterrell&gmail,com> on Tuesday November 25, 2003 @04:55PM (#7561888) Homepage
        We are talking about Java here. I could just use web-start. It's quite nice.

        I spent 1 month looking at all the enterprise level technologies out there (You know... anything with distributed transactions, RMI of some sort, and security infrastructure). I spent 3 months learning J2EE. I spent 3 months looking at different frameworks. I eventually decided to go Web-Start. I really really wished there were books that compare the technologies out there based on performance, popularity (increases the number of jobs you can work at and the number of employees you can pick from), and time to completion (ease of use). Java almost has too much choice.

        Here are some questions that should make my point.

        How do you want to access your data?
        JDBC, JDO, Hibernate, CMP, or some weird object-database?

        What reporting package do you want to use?
        Custom (using iText, FOP, or just plain AWT to the printer?)
        JasperReports
        JFreeReports
        or one of the plethora of commercial packages?

        What kind of client do you want?
        HTTP, Web-Start, Standalone, or SOAP to Mozilla or .Net or Perl or etc. ?

        If you go HTTP, what web framework do you want to use?
        JSP/Servlets directly, Struts, WebWork, or some conjured up Velocity template?

        If you go Web-Start or Standalon, what GUI TK do you want to use?
        SWT, Swing, Thinlet, Luxor, Swixml, AWT (for 1.1 compatibility), etc.

        Do you want MiddleWare? What kind?
        Session Beans, Message Beans, Message queue's and some custom apps... with or without SOAP? Would you like a nice XML-RPC to go with that? Maybe you want something a bit more network centered like Jini? Maybe you have to work with some old CORBA software.

        Oh, BTW, what operating system do you want to run it on? (Linux, Mac, BSD, Unix) What application server? (JBoss, Jonas, Pramati, WebSphere, WebLogic, SunONE, JRun, Resin) What database server? (MySQL, PostgreSQL, Oracle, DB2, McKoi, Hypersonic, Firebird, MS SQL) What JVM? (SUN, IBM, JRocket) Do you need charting for your reports? (JFreeCharts, bah... just search google for java charting)

        My head hurts now, and I want to cry. When someone ends the madness, please wake me up and tell me what year it is, and which packages I should use, because if I look at them all, by the time I'm done, I'll have to start all over.

  • turbine (Score:2, Interesting)

    by Leonig Mig ( 695104 )
    has anyone tried turbine? i'm just getting the hang of it, as it seems like a more coherent and quicker way of getting going than struts? i quite like it now, wondering if anyone had any reservations who has had an experience with it.

    thanks.

    • i'm working on a turbine based project right now. the framework has some good concepts (services, user management, security), but the project organization is seriously lacking discipline. things don't always work as advertised, and if you're building a large-scale app, be prepared to dig into the turbine source and do some hacking.

      there's also an issue with turbine 2.3's (latest/greatest) choice of build systems. you are required to use maven, a project management tool built on top of ant, and that proj

    • Ask this on the turbine mailing list. Or better yet, RTFM!

  • Sample chapter (Score:4, Informative)

    by akuzi ( 583164 ) on Tuesday November 25, 2003 @03:29PM (#7560957)
    You can read the first chapter here [cup.org].

    Unfortunately, like the 'review' - it doesn't mention which frameworks the book covers though.

  • Application frameworks vs webapp frameworks (Score:5, Interesting)

    by smagoun ( 546733 ) on Tuesday November 25, 2003 @03:34PM (#7561026) Homepage
    There are plenty of webapp frameworks out there, but are they really the right way to write an app? Picking a technology (like servlets) and then writing an application based on that technology - or based on a framework that wraps that tech - is fundamentally broken for many apps.*

    The problem is that technologies change over time. Tech-oriented frameworks make writing the app easier in the short run, but they don't consider the long-term life of the app. Applications that are tightly coupled to any given tech become a liability as that tech ages, and quite often migration to a new tech involves a ground-up rewrite of the application. Instead of tying the app to a framework like Struts or a tech like EJB, write the app to stand on its own, using interfaces to the various techs it needs. Particular technologies like Struts (for a web UI) or EJB (for persistence) can be swapped in + out of the application as necessary without changing the function of the application itself.

    There are a number of benefits to a technology-agnostic approach like this. The technology implementations can be upgraded: find out that EJB is a dud? Switch to Hibernate! Perhaps more interestingly, the technology implementations can be supplemented: Have a web UI, but need to ship a desktop application too? Plug in the desktop app tech implementation and presto! You now have both a web UI and a Swing/SWT/etc UI for the same app. Testing becomes far easier too, because you have clearly defined boundaries between the different components of the app (so it's easy to figure out which part isn't behaving).

    There are drawbacks, of course. To work as advertised you need to invest a fair amount of architecture to get such a system off the ground. Someone has to write the tech implementations, as well - an SWT UI for your app won't just fall out of the sky when you want it.

    Everyone has their pet project. Mine is Sandboss [sandboss.org], an approach to enterprise application development that's application-centric, not technology centric. It concentrates on the app itself - you don't wind up with a "Struts application" or an "EJB app". Instead you wind up with an application that can use Struts and EJB, but can also work with Hibernate and WebWork. It's not for everyone - it requires a fair amount of committment to the methodology - but it works well in practice. The time savings are pretty incredible, and the components really are reusable.

    *There are many places where a front end for a database is all you need. Of course, once the requirements for that project start to grow you'll wish you had something more powerful.

    • Just a nit to pick: Hibernate != EJB. Hibernate is only a replacement for CMP.
    • What your describing sounds a bit like a project I'm involved with, Keel, a "meta-framework" for lack of a better term. Application-logic oriented, framework independant, switchable implementations (we just added an implementation to use Hibernate for one choice as persistence, for example). Quickly looking at the sandbox.org site, it sounds like there might be a lot of synergy between the two. Feel free to drop me an email directly if you want to kick that thought around a bit... Mike
  • Just curious...

    Personally I prefer the Framework provided by J2EE. It seems most frameworks just add a redundant layer on top of that, repeating the same functionality.

    It's been a while that I took a look at Struts, but what's the main advantage of a Struts Action over a Java Servlet? I think they are actually both meant to do the same thing. As far as I remember, the Struts Actions even get the HttpServletRequest passed as a parameter.
    • I'm overwhelmed by your in-depth analysis of the differences between J2EE and Struts. I think there might be a little more to it, though. Consider rechecking your sources.
      • I'm overwhelmed by the depth argumentation. Anything else you might provide in favour of Struts? I just checked the Struts User Guid, but couldn't find anything that made me want to read further. So what's the advantage of using a Struts configuration File rather than web.xml?
        • So what's the advantage of using a Struts configuration File rather than web.xml?

          I think none, and I'm quite sure it won't work -- you human paraquat!

        • From minimal exposure to STRUTS, decoupling of navigation logic from JSPs and Servlets, plenty of basic field validation / error message handling goodies, basic enforcement of MVC (of course, you can break that). Not a STRUTS expert though, so if I'm wrong don't be surprised.
  • I am currently involved with major Java project at big big government agency.
    Every new body on the team gets to sit and read the Struts book - it takes govnt weeks to get you a PC and months to hook it up.
    But the application they eventually get to work on is a terrible mess of logic-laden JSPs, clueless beans and stored procedures doing String manipulation.
  • If it doesn't include Open for Business [ofbiz.org] it is already out of date and missing the best piece of code going. The problem with the open source community today is that we don't mind using a few tools like Linux, Apache, etc. but when it comes to doing something that really would make business applications less expensive and of higher quality - like agree to standardize of a select few frameworks - we don't!
  • Pasta

    When I cook pasta, and I am in a hurry, or I don't care if it tastes a little different to how I want it to, I buy a jar of premade pasta sauce.

    When I am cooking for a special occasion, I wouldn't even dream of it. I know how to make a killer sauce, so I can make my own from scratch. The taste is always tailored to the occasion when I do so. The only other consideration is that it takes longer.

    Curry

    On the other hand, I do not know how to make curry from scratch. Thus, no matter what the sit

  • I am sorry but a comparison of frameworks with very rushed case studies means a bad book on frameworks..


  • The problem with general frameworks is that they are often too general. The wave of the future is going to be business specific application / database servers that are stitched together with open messaging schemes.

    So, instead of having one general framework with a middle tier in some webish / code combination talking to a SQL server, you'll have a messaging bus that stitches together various domain specific database servers.

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close