Manning's Struts in Action

cpfeifer writes "Building browser-based java applications has involved a mixed bag of server side technologies (servlets, JSPs), client side technologies (HTML, Javascript) and frameworks (webmacro, Struts, Taglibs, Velocity). As these technologies appeared and matured, "The Right Way" (tm) to build web applications evolved to be an application of the classic model-view-controller pattern." Below is Craig's review of Struts in Action, a book which attempts to illustrate a successful path to making sure that web applications are designed the right way. Struts in Action author Husted, Dumoulin, Franciscus, Winterfeldt pages 630 publisher Manning rating (11/10) it goes to 11 reviewer Craig Pfeifer ISBN 1930110502 summary More than just a book about how to use the Struts framework, covers the best practices of web application design and development. If you are building a java web application of any appreciable size, YOU NEED THIS BOOK.

What's Needed So it is generally acknowledged that using the MVC pattern is the proper way to build web applications, but with the large number of technologies and frameworks it can be a long road to figure what is the best solution for your application. What we need is a book that covers the best practices of web application design and development from both a technology/architecture perspective, and is written by a few folks who have deep understanding of the underlying problems of building robust web applications.

That's what I love the most about this book, it doesn't just talk about how to configure and develop with Struts. It's a web application manifesto. Anyone can write a book about how to use Struts to build a web application. That's not the point. This book is ~8 people-years worth of first-hend developer knowledge (4 authors x ~2 years of working on the Struts project) condensed down into 630 pages. It doesn't just teach you how to use Struts (and Velocity and Taglibs and Tiles), but why you should use them. That's the most important thing this book has to offer. If your project is looking at using Struts & other Jakarta technologies, you need this book. If your project is currently using Struts & other Jakarta technologies, you need this book.

What's Bad?

The Velocity coverage is pretty light. If you are more comfortable building logic with a quasi-shell script language instead of using markup tags, then you should look to the project's documentation for further reference before embarking on a prototype. The Jakarta Lucene project, is touched on in the sample application they build, but are left as an exercise for the reader to investigate. While it's good to bring in related technologies to flesh out your sample apps, you have to be careful not to get sidetracked from the primary topic. You could easily write several books about the other components developed by the Jakarta project.

What's Good?

The best part is that the 4 authors are all Struts authorities (one Jakarta project manager, 2 Struts committers, one principal consultant), so they know Struts and the other Jakarta web frameworks inside and out. More than that, these guys have been solving the problems involved with web applications for several years now. They have deep experience in the patterns and best practices of building robust and flexible web applications, and this book passes on their experiences to the reader.

So What's In It For Me?

With this book and a little bit of effort on your part, you will be a competent Java web application developer. With a little bit more effort, you will become a Java web application architect. It's worth the extra effort. This is a tremendous book that will set the standard for web application references and will continue to be useful for years to come. It reminds me of the first Manning book I read, Neward's Server-Based Java Programming in terms of it's scope. approach and usefulness.

You can purchase Struts in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Who still uses structs? Tapestry the way to go :)

[cjustus]

Am I one of the first to follow up? Sweet

People considering using structs might want to take a look (as you always should) at alternate technologies... The one I might suggest would be Tapestry with IDE integration with Eclipse through Spindle.

What a big ball of complexity

[photon317]

I don't need a diatribe on MVC or that whole list of blubber strapped to a bloated environment to write good web apps. Perl generating XHTML and CSS makes wonderfully simple and easy-to-use web apps for me.

Re:What a big ball of complexity

[Cap'n Canuck]

Yeah, but do you write commercial web-apps? Ones that are complex? What's your definition of "Good"?

Re:What a big ball of complexity

[FortKnox]

Yeah, for personal websites and such, no major MVC and EJB and other J2EE is necessary, but if you have a enterprise size 50+ page site that requires all the wizbangs and is complex (like online banking), good luck designing all that perl.

Re:What a big ball of complexity

[THEbwana]

...and more importantly - when you look at your perlcode after coming back from holiday; can you still see what it does/how it works? /m

Re:What a big ball of complexity

[photon317]

See response to other comments above

Re:What a big ball of complexity

[photon317]

I'm annoyed that moderators have called me flamebait yet again for a valid opinion, and that the responders assume that I must not know what I'm talking about.

I'm just now going through QA testing on a commercial web application load-tested for 1000's of users, all highly secure, handling sensitive medical transactions. It backends to a complex postgreSQL database tracking user transactions and security audit trails, etc, etc...

It's well beyond a web banking interface or anything as trivial as that (referring to the other reply to parent). And yes, I can read my code after the holidays are over. The only practical consideration is that most of the world's web programmers are Java now, so if we ever sell the source/company nobody will buy it for fear of not finding an adequate person to maintain it perhaps. But as long as it's our company and we can hire replacement Perl programmers, it's all good.

Re:What a big ball of complexity

[TheLink]

Actually online banking shouldn't need to be that complex. Complex = more likely for security problems. Keep it simple. Sure the bank's actual backend could be a mess, but that doesn't mean the online banking webapp has to be. Hmm actually perl is pretty good at gluing messes together. Like with like perhaps ;).

BTW not sure why many banks use tons of javascript here and there on their website, pop up windows, pages that rewrite themselves, etc. That style worries me - almost everytime I see a website doing that, I've found easy to exploit problems.

So far I've found security probs in 2 out of 3 online banking sites I've looked at. The 3rd had so much javascript you could barely see the HTML so I didn't bother - I could use a proxy in between to transalate and send custom data to the site, but nah - not like I'm really trying to exploit things.

Now something like windows update is probably complex (more client side complexity tho) and needs the whizbangs. I couldn't update for a couple of weeks and I thought my Windows installation was broken, then one day the Windows Update website looked different and it worked. Doh. Too bad with Windows you can't synchronise sources and make buildworld, etc... ;).

Wow!

[stratjakt]

"So it is generally acknowledged that using the MVC pattern is the proper way to build web applications"

MARVEL VS CAPCOM!!!!!

Ha-DOOO-Kin!

You must defeat my java applet to stand a chance!

Re:Wow!

[Anonymous Coward]

Shoryuken!

Re:Wow!

[Anonymous Coward]

Arooo-errgh! Aroo Aroo-errgh!

Web application security papers

[Anonymous Coward]

www.cgisecurity.com/lib

web based applications

[mark_lybarger]

round h.. meet mr. square peg. it's amazing the many hoops and tunnels people will go through to put their "application" on the web. web is a great tool for presenting information. i would have thought the internet fall of 2000/2001 would have brought alot of companies back into check, but that doesn't seem to be the case.ole

Re:web based applications

[TrekCycling]

Except that web applications are easier to manage and distribute if they're done right. i.e. no visiting every desktop, think clients. The key part is done right, however.

MVC to all who say "I just write..."

[MosesJones]

MVC is about design, its about knowing that your application will be maintained by other people. Its about seperating the various elements so multiple people can work on your project. Its about ensuring that elements are re-used effectively so testing effort is used more effectively.

MVC is about projects that work well. So to all those people who just "hack it together on my own", please remember that there are some people out there who do this for a living on sites and system that will still be maintained in 5, 10, 15 years or even longer. That is why you choose MVC, because you realise that Go-Live is only a small part of TCO.

MVC is great, and MDA is even better because it uses similar patterns at an even higher level.

Design is good, design works, patterns work. Just because you can "write 1,000 lines in a day" doesn't mean that in 6 months time even YOU will be able to maintain it. Don't knock it until you've been on a project with 10 people where they all thought they could do it their own way.

Be an engineer, not a script kiddie.

Re:MVC to all who say "I just write..."

[FortKnox]

I completely and totally agree!

I'm sick of children that say "Hell, I coulda done that in like a week, not 3 months!" This is the difference between coding all hours of the night and true professional development.

This is, unfortunately, an issue with several open source projects. Someone just starts slapping code together, and more and more people jump in and have coding binges over the weekend. What do you end up with? A bowl of spaghetti code that only the original writers can understand.

If major design was implemented from the start, a lot of open source projects would be easier to help out (I hate to say this, cause it will sound like a troll, but slashcode really needs rewritten from scratch with a better design than what it currently has. Honestly, if it was well written, I think a lot more people would be willing to pitch in and help out.)

Re:MVC to all who say "I just write..."

[Tar-Palantir]

The MVC approach to software design is highly encouraged in Mac OS X Cocoa development. It's used in the AppKit and Foundation frameworks and in many applications.

I had never heard of it before learning Cocoa, but I was converted real quick. Using model-view-controller truly improves an application, even a small one.

The true advantage of MVC, in my opinion, is that it makes the application logic clear and reusable, even in single-programmer situations. It isn't just for multiple-person projects as described by MosesJones above.

Re:MVC to all who say "I just write..."

[axxackall]

This is, unfortunately, an issue with several open source projects.

You may mean PHP, I guess? I agrre, it's complete mess of spaghetti.

But in a defence of open source project (especially based on something else than on proprietary java) I would address you to Zope. You'll find a very good technology design without all that EJBish overbloating.

When you run Zope, please check you memory. Compare it to what you have with Struts/JBoss on an equal load and equal functions (and equal dev time). In my case the difference was 10 MB vs 100 MB for a mid size applications.

After that compare you code just to enjoy that your application code in Zope is even more readable and better mainanable than in Struts.

I began to hate EJB specifically and Java generally when I've been introduced to Zope and Python.

Re:MVC to all who say "I just write..."

[xod]

Patterns and UML are fine, and MVC has its place too, but currently it's overrated, suffering from the hammer/nail syndrome. Check out this article on why in many cases, real OO is better than MVC:

Re:MVC to all who say "I just write..."

[drewmca]

I agree strongly. I think that people fail to realize, from management on down to the trenches, that the real cost of software development is in maintenance. If you write a really nice subtle piece of code that saves processor cycles but is hard to understand, any performance gain (or points you give yourself for programming skill) will be completely offset by the time spent by other developers or you trying to figure out how it works a month or a year down the line. Very little code goes through its lifetime unaltered; things get added, removed, extended, etc., all the time because of business pressures. The harder this is to do, the higher the cost. A perfect example of this is in variable naming. So many people I've worked with continue to use cryptic variable names like "chks". Wake up people! We no longer need to deal with the limitations of computers from 10 years ago! We can actually use long variable names without a performace hit! Isn't it about time our programming style changed to reflect that? Wouldn't it be easier to have a variable named "checks" so that other people could understand what was going on in the code? Or so they wouldn't confuse it with another variable "checksum", for example? Of course, there's a fine line where too much design slows things down. You can't overengineer. I like a lot of what the XP people say about this, especially with the one-two punch of strict unit testing and refactoring.

Re:MVC to all who say "I just write..."

[Pengo]

I have found that I have made the Python round-trip.

I haven't used Zope, but for general programming..I have found my programs to build up quicker using python.. but , even when push comes to shove.. my java apps are more maintainable. Agreed that JAVA is a bit of a pig, but it's a VERY structured language. Having soft-types in Python seems to be what kills me in the long run, my programs tend to be more 'brittle'.

Also, using tools like ANT and now my new golden-child of IDE's , Eclipse.. I find JAVA wasn't as bad as I thought..

I can also use Jython anywher ein my java apps if desired.

Re:MVC to all who say "I just write..."

[heathm]

Yes PHP is good for quick and dirty stuff but it turns into spaghetti very quickly. Zope is only one step up on the ladder, though. If I had to maintain Zope code 5, 10 or 15 years from now, I would probably kill myself. Zope itself still follows the "I just write..." mentality that is absolutely stupid. It's the same spaghetti just in a nice bowl with meat balls.

I've been using Zope for about a year now and all of us working on the project have come to the same conclusion; Zope is the spawn of Satan.

Using memory footprints to compare two platforms is asinine at best. Sure Struts/JBoss uses more memory but who cares? Memory's cheap. The power, flexibility and speed that comes with Struts far out weighs the measily 90MB.

Sure you can get started on a project quickly with Zope but that's all the goes out the window in a hurry. Try using Zope with CVS. It's a nightmare. Try developing a real application with multiple developers using Zope. It's even worse. There's no real MVC design patter with Zope. Maintainability doesn't mean that *I* can go back and change something a ways down the road. It means that myself and *others* can change things down the road. It means *multiple* people can work on the same project at the same time. Zope doesn't handle that effectively at all.

Does Zope have potential? Possibly. Is it good for prototyping? If you avoid DTML, yes. Is it good for any kind of real enterprise worthy application? Not a chance.

I started to love Java specifically and EJB generally when I found it could do all the thing I wanted to do that Zope just can't.

Re:MVC to all who say "I just write..."

[thammoud]

Actually the article that your referred to is one of the worst that I have read in a long time.

>>Never ask an object for the information you need to do something; rather, ask the object that has the information to do the work for you.

Lets see, If I want to have the object render itself, then it must deal with the GUI toolkit. How about persisting itself ? It has some SQL in it. Hmm. How about serialize itself as XML. Maybe some added XML code will round up the meal.

I do not want to be the maintainer of this object. The article makes no sense whatsoever. Unfortunetly, I see the 'object that can do it all' everyday. This is akin to a shopping cart knowing how to check itself out. I had never seen a real shopping cart that can do that. I go through the cash register.

Re:MVC to all who say "I just write..."

[some guy I know]

We can actually use long variable names without a performace hit!

Long variable names aren't always better.
A long, long time ago (late 70s), before I knew any better, I once named a variable named something like "INTEGER_VARIABLE_USED_FOR_TEMPORARY_STORAGE_PURPO SES".
(Yes, I thought that I was being funny.)

Sometimes, naming a variable "i" results in more readable code than naming a variable "index".
Also, I usually name as "r" the variable whose value will be returned from a function, when such a variable is necessary.
I do agree with you, though, that, in most cases, a fully-spelled-out variable name is preferable to its abbreviation.
However, there are exceptions even to that rule.
For example, IMO, "lib" is preferable to "library" when referring to a software code library (although "library" is preferable when referring to a book-library object).

The thing about MVC

[dmorin]

This is probably off topic, but I just got off the phone with somebody talking about MVC. In my experience thus far, MVC often falls victim to "Yeah, it's a good pattern in theory, but in implementation it's going to make my life harder by forcing me to separate things that I don't technically have to separate." When people create their own stuff from scratch I think that they often get close to MVC but don't fully realize it. We had this problem with Struts in our platform. We have a homegrown forms library on top of a proprietary app server. When the time came to rewrite it in open source we started by looking at Struts and decided that Struts added too much complexity, that we could port what we had more directly and get running faster. Of course, after doing that, we all knew that Struts was where we wanted to be long term so we started designing a plan for getting it in there.

Random MVC joke. Saw a cartoon in a Java mag once where a project manager is saying to his engineers, "For this part of the user interface we can either go with a Swing applet, or ActiveX control." Engineers all chant "Swing!Swing!Swing!" Project manager says, "If we go with Swing, it will require substantial work with JTree." Engineers all chant "ActiveX! ActiveX! ActiveX!"

:) Duane

Re:The thing about MVC

[wickedhobo]

This really depends on some factors. First, for small projects, MVC architecture can be quite a bit of overkill.

However, for large projects that require extensibility, performance and tier separation, it can't be beat. I just finished a massive project for the US government using Struts, and if we hadn't used it changes, new features, and maintenance would be much more difficult. Struts and MVC was a good choice for this project

On top of that, with zero Java scripting code in the front end, it's much easier for people to make changes to the look and feel. On top of that that, I can rewrite the entire logical tier without having to rewrite the front end since we used the typical Value Object pattern that you see so often in MVC's.

The only downside to struts for me is that it relies on URL Mapping too much, and that can be a little cumbersome. I do like Tapestry's object model, but it's not as robust, I think, as Struts. Tapestry is a great project though.

On the other hand, the good thing about URL mapping is that it allows you to move your JSP's out of the regular directories above WEB-INF to secured directories below WEB-INF. For workflow and secure environments, this can be a really great plus. It ensures that people can only reach workflow and resources through the proper means.

-Wickedhobo

Why use struts? Just do it yourself.

[zaqattack911]

Everytime I go back and consider using struts.. I keep realizing I already use the MVC. Struts too me seems like extra bloat.

Basically I have a master url such as: http://mywebsite/servlet/IndexServlet (lets just say).

The master servlet always takes in an "f" parameter to determine state. f=login , f=mainmenu, f=saveform, etc...

It uses that f parameter to pull out the proper "Action Object" (or control) from a stored hashtable that is initialized once. Then it executes that ActionObject (or whatever you choose to call it) which handles the other parameters (other than f), does what it needs to, and pushes out the proper JSP "view" of your choosing.

This could be simply displaying a form, saving a form to database and displaying a success page, yadda yadda yadda. Of course some actions can be used for more than one thing if you code smartly.
I have saved eons of time doing this this way, making my "ActionObjects" as reusable as possible.

All along security is maintained via sessions.

It's easy, and you don't need third party libs to do it.

Commentary and questions are welcome of course. I expect half of you have come up with some flaws :)

--Zuchini

Re:Why use struts? Just do it yourself.

[billtom]

There isn't any particular flaw, but there are two other points to consider.

First, what you've described is only about one quarter of what struts does. A very important quarter, of course; the core of a common web application pattern. As to all the other stuff that struts does, there doesn't seem much point in listing it here. Check the site.

Second, look at what you're saying. You're saying, "I can write code that does what struts does". Sure, by why write code when a good third party library is already there. I could summarize the code required for a simple web server in a few paragraphs, but that doesn't mean that it's a good idea to write one for every new project.

Re:Why use struts? Just do it yourself.

[BigChigger]

Providing direct access to a servlet is considered a security breakdown.

BC

Re:Why use struts? Just do it yourself.

[pcraven]

You are absolutely right, you don't need struts for that. I did something similar (along with 8 zillion other people). Our 'ActionObjects' could also specify a view object. We had views for JSP, XML, portal pages, etc. Very lightweight and easy to understand. (Struts is not easy to understand for beginners.)

You also don't need libraries like log4j for logging. Logging is easy, right? (That's what I thought until I started using log4j. Holy cow, the things my logging can do now...)

But struts has many add ons for form processing, db connection handling, controller options, dynamic form object creation, dynamic validation, error handling, internationalization, page layout, etc. And it makes it easy to make your own add-ons.

So now I can work 1 or 2 days a week, and get everything done that I used to do during the whole week. The rest of the time I can spend playing around with other stuff.

Right now I'm trying to figure out if Java Data Objects are worth while. Right now it makes my code slightly smaller, but adds lots of xml. And I'm suspicious it is slow. But these were some of my same unfounded complaints against struts when I started.

Re:Why use struts? Just do it yourself.

[Bazzargh]

You're right that simple MVC webapps are easy, but the easiest approach is actually the one described in this article by Govind Seshadri.

What your approach misses that you get from Struts:
- validation of form submissions (to java types, regexps, whatever)
- automatic population of form beans, which leads to...
- automagic prepopulation of forms from beans used earlier in the session (with struts custom tags)
- tool support for designing complex sites (there are lots of GUIs for struts these days)
- you don't need to write or maintain any of the framework :)

Every framework brings with it some constraints in how you work, but pays off in spades if you use all the features. Struts is no exception. If all you're doing is the stuff you describe, Govind's article might improve your life a little. If you build complex sites, Struts will simplify your life a lot.

Just a quick concrete example: in struts, the equivalent of the IndexServlet you describe is the DispatchAction. You'd configure like so:

Then you can write:
package funky;
class IndexAction extends org.apache.struts.actions.DispatchAction {
public ActionForward login(...);
public ActionForward mainmenu(...);
public ActionForward saveform(...);
public ActionForward etc(...);
} ...and the methods are automatically called depending on the value of 'f'. Like you said, "Of course some actions can be used for more than one thing if you code smartly.", and in this case the smartly was done for you ;)

-Baz

Re:Why use struts? Just do it yourself.

[Bazzargh]

Sorry the config bit got chopped out - I wroute:

<action path="/indexAction" type="funky.IndexAction" name="indexForm" scope="request" input="/index.jsp" parameter="f">

Re:Why use struts? Just do it yourself.

[jkauzlar]

A breakdown in security? I can see it being a breakdown in MVC.. can someone elaborate on this?

Re:Why use struts? Just do it yourself.

[zaqattack911]

I could summarize the code required for a simple web server in a few paragraphs, but that doesn't mean that it's a good idea to write one for every new project.

Shit I wrote my own webserver too :) (only for highperformance specific uses of course).

It's not like I have to re-write my Webapp "Controller" every time.. I did it once.

What is Struts?

[SnapShot]

Could someone give a quick overview of what Struts is/are? Is it a technology, a language, or just a term given to a way of doing things?

Re:What is Struts?

[FortKnox]

Struts is an online J2EE framework that utilizes the Model View Controller pattern. Look on the website for a good overview.

Re:What is Struts?

[Fjord]

Struts is a "framework" that you use to build J2EE applications. It dictates a lot of how you build your applications inorder to make them more likely to conform to MVC (although if you want to you can break the MVC model quite esily). It's really a lot of things put together, there is a dispatchng mechanism dirven by an XML file, there's input resolution by matching parameters to bean attributes. There are tag libraries that make developing JSPs a bit easier (like the tags that autorefill the input fields. Nothing too staggering though).

Nothing the stuff in struts is revolutionary, and there really isn't anything there that we have done before Struts came along. However, a good thing abotu Struts is that it is both open and becoming an industry standard. That way, if you come into a new development shop and have Struts experience and they use Struts, you have less to learn about how their application is modelled. If you don't know Struts, then you learn it knowing that the knowledge is applicable at other jobs. I'd say that is it's only, but a very strong, advantange.

More info on Struts in Action

[Cap'n Canuck]

There's a site called JavaRanch, which has some useful forums for the serious Java developer. If you participate in their "Open Source Projects" forum, you'll be entered into a draw to win a copy of the book.

Also, one of the authours (Ted Husted) will be on-line to answer questions. Note that you need to register - No Anonymous Cowards!

MVC vs. Morphic

[Anonymous Coward]

I'd sure like to read a hundred words or so about the merits of Model View Controller vs. Morphic http://www.squeak.org/features/graphics.html (scroll down a bit). Anyone out there up to the job?

Re:MVC vs. Morphic

[gezerk]

I am probably not qualified to spout a hundred words on the topic but I can tell you that the comparison you are asking for may not be an apples to apples comparison in the context of a discussion on Struts.

Morphic is a "direct-manipulation User Interface (UI) construction kit" (scroll down to see relevant section) for Squeak. Squeak is "an open, highly-portable Smalltalk-80 implementation"

MVC as it relates to Smalltalk is slightly different than the MVC Pattern talked about in this context. MVC in Smalltalk terms is the name of the actual GUI, as well as a the paradigm behind it. Morphic may be a replacement for MVC in a Smalltalk/Squeak discussion, however in the MVC as pattern discussion, Morphic is not at odds with MVC, it is an implementation of the MVC pattern.

A discussion of Morphic vs. Struts would be in order if Morhpic ran in a Java environment, or if Struts worked in Smalltalk.

Struts

[FortKnox]

FYI - Struts is quickly becoming the framework of choice for all J2EE coding houses. Having struts experience is a huge plus on your resume. The other Java tech to watch out for is portals (ie - jakarta's portal engine, or WebSphere's portal engine).
I digress, but I've used struts and the MVC pattern plenty at my job, and it just makes life so easy when adding in new functionality, fixing bugs quickly, and overall maintainability.

Those that say "its good in theory, not in practice" haven't used it correctly in practice.

Re:Struts

[Anonymous Coward]

Could you cite some statistics, research, etc. that proves your assertion that Struts is the "framework of choice for all J2EE coding houses"?

Just because you use it in your job doesn't mean you can extrapolate this to include all development groups in the entire IT J2EE industry.

Re:Struts

[rfsayre]

It's also becoming part of the J2EE spec in a slightly altered but hopefully interoperable form.

Sun is calling it JavaServer Faces. Principal Struts developer Craig McClanahan is on the committee.

Re:Struts

[Runny]

JavaServer Faces IS NOT Struts. Please read up.

Can we have a consensus here?

[Twister002]

IS MVC really the best way to build web applications? It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?

Does Slashdot use an MVC pattern? MSN? Yahoo?

Re:Can we have a consensus here?

[Anonymous Coward]

Dude, have you ever downloaded and examined slashcode? Ugh.

Great idea, horrible implementation. Yes, it's used by a ton of people. Just like Windows.

Re:Can we have a consensus here?

[heck]

MVC is NOT right for every project, and it is not the best way to build all applications. Neither is PHP, Perl, C, C++, FORTRAN, ASP, etc. You pick the tool you need for the job, the one that is right for the company you are with, the one that is right for that project, etc.

People such as myself who are pro-MVC are not saying "MVC is right for every need". MVC is one of the many tools you need to have in your bag if you're calling yourself a Web developer or say you know "Web services".

As several of the other comments have said, speed of development is only one factor in the cost of a project.

Other costs are: can I change it easily as the business needs change, or as back end systems change? Can I easily add modules? Can I easily go back and optimize a piece of code that 3 months of use has revealed wasn't written correctly and easily switch that code in and out without impacting other modules? Can I keep the people doing the view (typically graphics artists and Web editors) and people doing the actual logic of talking to the back ends (geeks, in other words) concentrated on their area of expertise? Do I need to hire generalists (people who can do view and model/control, and there aren't many of them. That's why a lot of interfaces look like crap, or a lot of great looking interfaces run crappy)? Does a change in look and feel cause a major headache for all?

Re:Can we have a consensus here?

[eddy the lip]

You can implement MVC in any language. I've built one using PHP that has made development of complex web apps many times faster and easier to maintain than some random collection of pages with SQL embedded all throughout them. One page takes the request, makes the appropriate calls for whatever action is being taken (just a collection of included files, really), and they rely on a series of objects to do the actual heavy lifting - manipulate data, interact with the database, etc. Designers can change the look of the site without ever touching a line of PHP, coders can change the way the backend works without ever seeing any HTML. And once the framework is in place, you never need to worry about it again.

For a simple one-off mailing form or some such, there's no point in the more complex architecture. But if you need to perform many different operations, aren't sure what the client's going to ask for next, and want to be able to change how things look or work without poring through miles of unrelated cruft, it's a godsend.

To a large extent MVC is about injecting a big load of discipline into your work so you only need to worry about the relevant portion of your app instead of the whole spaghetti mess of it. In the short term, you can probably pull something together "that works" faster just by sitting down and coding, but the long term benefits more than make up for it.

Re:Can we have a consensus here?

[bbqBrain]

I think the Struts framework fits the web app model quite nicely. Decoupling the components of your application correctly encourages better design decisions and results in more reusable components.

For example, a problem that comes up in just about any web app I've ever seen is that the user must be able to:

1. create some kind of record (data object) by completing a form
2. see this information later in a read-only mode
3. modify it in an editable mode

To digress briefly, in Struts, the developer defines "actions", which basically comprise a FormBean, Action class, and a JSP (the JSP can be selected from a predefined list at runtime based on a return value from the Action class). The FormBean holds any data needed for the view, which will typically include attributes for any form elements as well as any necessary metadata. When a user requests a view (aka "action"), the Struts engine reads the XML config file (which holds the action definitions) and passes the request along to the appropriate Action class. The Action class can analyze the request, as well as the FormBean, to determine what needs to be done, calls business methods as required, and returns a value to the Struts engine. This value maps to a "forward" entry in the config file, which simply directs the request to a given JSP. (see http://rollerjm.free.fr/pro/Struts.html for more info)

Getting back to our example, the 3 cases mentioned above can be accomodated by 1 action entry in the config file. It would be something like:

<action path="/userInfo" type="com.acme.proj.struts.action.UserAction" name="userForm" scope="request">
<forward name="create" path="/editUser.jsp">
<forward name="view" path="/viewUser.jsp">
<forward name="modify" path="/editUser.jsp">
</action>

(the name, "userForm", is a logical name for the FormBean; it is mapped to the actual Java class elsewhere in the config)

Anyway, the Action class and FormBean together know everything about what represents a User and what can be done with one through this app. The JSPs are responsible for presenting the User information and any options for performing actions on a User (delete, update, etc.). In fact, the "create" and "modify" forwards even map to the same JSP. Presumably, the Action class would set some kind of flag in the FormBean to indicate whether this is a new user or not.

This is the beauty of Struts. Once comfortable with the framework, one can knock out well-designed web apps very quickly...especially if a good set of custom tags have been developed.

Re:Can we have a consensus here?

[Phouk]

It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?

Yes. When not using MVC, you might well have to recode it 3 times. :)

Besides, you can do MVC in PHP / Perl, and you can code quick and dirty in Java.

Re:Can we have a consensus here?

[bwt]

Yes, MVC is the best way to build a web app.

You've got it backwards -- initial build times are going to be faster using Struts with JSP (say) than they will be using PHP or Perl. If you were talking about coding servlets directly in java you might have a point, but that isn't how Struts works.

Struts is written in java, but writing a web app with it will find you producing a lot of XML action bindings and JSP (most commonly) for the view layer. JSP is used in the view layer and JSP is easier to write web pages in than either PHP or Perl, no contest. The navigation actions are coded up in XML, which struts taking care of for you.

The action implementation classes that affect state in the model have to be written up in Java, but they'd have to be written up in something no matter what you use, and you don't have to code up the glue code that figures out what triggers what. Java is faster than both PHP and Perl, but the real advantage is in maintainability -- I pity the sorry sap that has to refactor somebody else's Perl or PHP. Most of an app's total lifecycle cost is in exactly this kind of expense as requirements change and integration happens with other systems.

Manning Press

[Frums]

I have this book, and JSTL In Action and both of them are truly excellent books. The 11/10 rating is quite appropriate. I have been attempting to convince myself to buy the Manning Ant book as well - just for the documentation on all of the Ant extensions that it includes.

Additinally, Manning Press has experimented with releasing PDF versions of books (in read only if you use acroread or windows, but not otherwise) and this was how I first met their books. (The books were hosted over at The Server Side). Anyway, this was my first intro to Manning Press. I now look over their books before any other.

The think I like most about Manning books is that they are written for smart people who have clues. Many tech books feel the need to explain basic concepts of programming in every single one, Manning doesn't bother - they stick to the topic on hand, they write as if the audience has a clue, is intelligent, and has real work to get done.

Struts and MVC

[giel]

IMHO using Struts (and web applications in general) you cannot build true MVC based applications.

The MVC model defines more communication options and knowledge between objects that Struts is able to provide. MVC is event driven, a Struts application is driven by actions (post or get).
The Structs framework, as I understand it, in general works like this:
- A http request is sent to some dispatch. This dispatch converts the request into an 'action'.
- The action is executed and returns a new request, either for a JSP or some other Template to be rendered or a new action.

Using MVC a view contains components that have corresponding controllers. The view is usually a predefined API to a collection of widgets (like AWT, Swing, etc.). The controller is built of events bound to the widgets.
Struts calls the jsp's the view, the actions the controller and the back-end or business logic you define the model.

However MVC allows the model to interact with the view, and there is no way you can be sure you will be able to do so with a web page, because HTTP only supports polling and not pushing if you want to keep things browser independant.
Well that's why I would not dare to say Struts implements MVC for web applications, but I must admit it provides a very nice framework.

Re:Struts and MVC

[gorbachev]

re: MVC is event driven

I would argue that what you have there is one IMPLEMENTATION of the MVC design pattern.

MVC can be a lot of things. In its core it's just a collection of abstract software design ideals. However you implement it is up to you.

Or at least that's the way I think about it. YMMV.

Proletariat of the world, unite to kill reinventing the wheel, use frameworks

Re:Struts and MVC

[ChannelX]

However MVC allows the model to interact with the view

By allowing the model and view to interact you've broken the whole reason for using MVC in the first place. You don't want coupling between the model and the view and that coupling is the point for using MVC.

Re:Struts and MVC

[revscat]

The MVC model defines more communication options and knowledge between objects that Struts is able to provide. MVC is event driven, a Struts application is driven by actions (post or get).

By your definition, then, MVC is impossible to achieve over HTTP. You go on to say:

However MVC allows the model to interact with the view, and there is no way you can be sure you will be able to do so with a web page, because HTTP only supports polling and not pushing if you want to keep things browser independant.

First off I'm not sure you're comparing apples to apples here. MVC in the desktop sense has both different connotations and expectations than MVC in the web sense. Using simple session management (either through cookies or URL rewriting) you can have a de facto state-ful application over HTTP wherein the view is affected by the model.

You seem to be maintaining a rather purist definition of "MVC."

Re:Struts and MVC

[eduardodude]

Thoughtful comments, but you're misinterpreting MVC and Struts. I think you're defining MVC in terms of Swing-like designs. Properly designed, Struts adheres nicely to the MVC pattern.

Struts _does_ provide an event model, but with very coarse granularity. A request can be thought of as an event, handled by an Action. The Action performs presentation controller logic (interpreting the request to initiate some work, get data used to render a page), but should delegate to the Business Tier to perform the business controller logic (persistance, business rules, etc.). A common pattern here is the Session Facade, although it by no means needs to be implemented using EJBs. The Controller is spread across two tiers, each with different responsibilities. The Model is used only by the facade implementation, interacting with the persistance.

The View in a webapp also can/should have widgets: taglibs. In typical Struts designs, they render a page using data prepared by the Action. But nothing prevents you from having tags which interact directly with the Session Facade, pulling out data directly.

Webapps will never look like Swing apps. Their designs map differently onto MVC components. ...I realize not all Struts apps factor out their layers to strictly follow the Blueprints. But large enterprise apps often do, and this maps pretty cleanly onto MVC.

heh

[zapfie]

I think I need more sleep.. I read that headline as "Many Sluts in Action".. for a second I thought /. was finally filling in a gap in their stories.

Agree 100%

[kin_korn_karn]

I was a jump-in-and-hack coder (self-taught, used to program as a hobby, etc.) and they finally convinced me that design works. The only problem with a lot of patterns is that they don't apply that well to a non-OO language. Hence, the rise of Java, which is designed, as a language, around patterns.

I still call myself a programmer, though, not an "engineer". Engineers build bridges, I just write programs.

Re:Agree 100%

[Anonymous Coward]

I just implemented (an ugly hack of) log4j in asp. If vbscript can take a design, anything can. You just have to trample all over the namespace. Look at the Linux source. C is all about global canstants.

Re:Who still uses structs? Tapestry the way to go

[bbqBrain]

Are you serious? I found Tapestry to be the worst framework I've ever used. When developing with it, I constantly felt as if I had to fight the tool to get anything done. I don't see how Tapestry provides anything that Struts and custom tags do not.

I realize that, coming from a MVC background (SmallTalk gui, Swing, and Struts), any component-based framework would require some mental adjustment, but I thought Tapestry was very counterintuitive. Perhaps the Eclipse plugin does all the plumbing for you, but if you need an IDE to make Tapestry usable, there is probably something wrong with the underlying model.

OTOH, if you find Tapestry easy to understand, go for it. Your brain must work quite differently than mine. :-)

Struts and O'Reilly

[pcraven]

I really like the O'Reilly book that just came out. Most of the chapters of this book went through public review, if I remember correctly. The book is very solid.

The real advantage of struts for me comes from its ability to handle forms. Regular expression checking of input is a great way to make sure you don't take in bad data. Not having to write this code, and code to handle and repost the page when errors occur, takes away a lot of the tedium of development.

What I don't like about struts is all the abstractions. New developers should start with the basics and work up. But no one has the time for that. So figuring out what is going on under the covers is hard to do. The O'Reilly book is pretty good at trying to explain some of this stuff. But there's no substitute for actually doing it.

And is it just me, or has 'real' coding started to go away? I spend half my time messing with xml config files anymore. I get more done, but it isn't as much fun.

Re:Struts and O'Reilly

[jkauzlar]

here here! I feel guilty anymore for wanting to write code myself. There are some truly useful and important tools and libraries out there, and Struts may be one of them, but shouldn't we be allowed to 'reinvent the wheel' a little bit without feeling like some sort of revolutionary? How else are developers to understand software design in an intuitive sense without some trial and error? I know we went through all of the trial and error in college, but colleges are way behind on web technologies (at least mine was two years ago).

There's nothing that can really be done about it, obviously. It is part of the necessary evolution of the system, but still, I feel the need to rant about it.

Where's the fine line between saving time & money (having good stewardship) by using a framework like Struts and exploring a technology like J2EE for better understanding, by trying things yourself? Is this to be done on your own time only?

Re:Struts and O'Reilly

[Anonymous Coward]

What did you do? Reply to yourself with a different account so you could pat yourself on the back? The odd use of anymore in both messages makes me believe so. And by the way it's hear hear, not here here.

Re:Struts and O'Reilly

[jkauzlar]

Is it possible to get a reply that is on-topic and not ad hominum? Must I also be so concerned with my spelling every time I post on slashdot? Its as picky at spelling mistakes as my java compiler is. Maybe I should send my code to you so you can correct the spelling, if you like doing it so much, and take the burden off my CPU.

BTW, I didn't reply to my own message. If it makes any difference to you, I happened to agree with something the original poster said. That highly arcane use of the word anymore was probably a coincidence.

And to avoid being completely off-topic, has anyone compared O'Reilly's struts book with Manning's? I've grown very fond of Manning's Java books after JDK 1.4 Tutorial and Bitter Java. Thanks for the help even though no one will see this because it is a reply to a lame mod 0 post.

Re:Who still uses structs? Tapestry the way to go

[gorbachev]

I've never used structs myself. What's it like?

Struts, however, has eclipse plugins as well providing very nice integration with that IDE.

Just in case you are interested in more than just fanboyisms.

Proletariat of the world, unite to stop reinventing the wheel, use frameworks

Re:Struts is a useless framework for useless java

[Anonymous Coward]

You're late for class...the short bus just left.

Did anyone else

[0vi_king]

Read the headline as Manning Sluts in action..?

A word of advice, do not cruise back to slashdot right after checking your email.

If you _want_ to do it youself that is...

[jaaron]

I don't think anyone will claim you have to use third party applications to create an MVC-based web app. In fact, if you look at the core of Struts, it's rather simple (which IMHO is what makes it so nice). Any decent java developer could write something similiar and many have.

I think the point is, why go it alone? When you can have hundreds of developers all working on and testing the same framework you end up with a lot more features and much more stable code. Sure I could write my own controler servlet (which is what Struts mostly is), but personally, I don't really want to have to write up the validation scheme, the internationalization features, the tag libs that make it easier to work with, and so on. With Struts, it's all there to begin with and it works. Additionally, when I hand over a Struts project to another developer or team, I can just say, "Oh, it's Struts based" and immediately they have access to host of documentation and an entire user community for support. I don't have to sit down and teach them how my special MVC magic works.

I could go on, but I really find using a popular stable project like Struts has a lot of advantages. And yes, Struts is not perfect. There are lot of other good frameworks out there. It just so happens that Struts is very close to how I and my coworkers developed web apps to begin with, so the convertion factor was minimal and the gain was incredible.

MVC, Xerox, proprietary? trade secret???

[dpbsmith]

In the eighties? Xerox PARC published a series of books edited/written by Adele Goldberg and others that were supposed to be the definitive description of Smalltalk. IIRC three volumes were published. Checking Amazon, I see "Smalltalk 80: The Interactive Programming Environment," "Smalltalk 80: The Language and its Implementation," not sure about the third.

Well, the fourth was supposed to describe the Model-View-Controller paradigm. IIRC the covers of the earlier volumes listed it as being fourth in the series, but it mysteriously just never appeared.

I heard that it had actually been suppressed by Xerox, which felt it was too proprietary to disclose, or something.

It's a pity, because all the descriptions of MVC I've seen have been sorta loosey-goosey and I've never seen a real technical description of MVC as the Xerox PARC envisioned and implemented it.

Anyone know anything more about this? Was the book ever published?

(Has anything about MVC been patented? THAT could get interesting... It's certainly a lot more worthy of patent protection than a lot of software patents...)

Re:MVC, Xerox, proprietary? trade secret???

[tpr]

The book never got written because Adele just didn't get around to it; at least that's what she told me.

MVC has been in use in Smalltalk systems for over 25 years. There are papers about using it, about the benefits and problems and alternatives; try looking up OOPSLA papers. If you don't know what OOPSLA is then wtf are you doing claiming to be involved in OOP? The code has been freely readable in the Smalltalk systems (just like all of it) ever since the very first implementations were created.

"Just write it yourself" and "Perl! Perl! Perl!"

[thelexx]

WTFever people. From the Velocity (which I prefer to Struts) site:

Velocity is a Java-based template engine. It permits anyone to use the simple yet powerful template language to reference objects defined in Java code.

When Velocity is used for web development, Web designers can work in parallel with Java programmers to develop web sites according to the Model-View-Controller (MVC) model, meaning that web page designers can focus solely on creating a site that looks good, and programmers can focus solely on writing top-notch code. Velocity separates Java code from the web pages, making the web site more maintainable over the long run and providing a viable alternative to Java Server Pages (JSPs) or PHP.

Velocity's capabilities reach well beyond the realm of web sites; for example, it can generate SQL and PostScript and XML (see Anakia for more information on XML transformations) from templates. It can be used either as a standalone utility for generating source code and reports, or as an integrated component of other systems. Velocity also provides template services for the Turbine web application framework. Velocity+Turbine provides a template service that allows web applications to be developed according to a true MVC model.

---------------------

Velocity is dead simple to use, as it is not some kind of entire 'framework' that wants to manage your DB connections, life, etc. It makes using JSP look like masochism. If you really feel like recreating the wheel though, and are convinced that you know better, etc. then feel free to waste your time. I pity the fool who has to maintain your cruft though.

(Would like to be posting more thoroughly on this, but it ain't happening this morning...)

how is this a book review?

[hashmap]

so where's the review?

What is struts? Why it is better/different than JSP? How is better/different from XML/XSLT transformations? What's the point in publishing a review that sounds like sales pitch?

I have not used Struts but from what I have seen these high-level solutions are a dime a dozen. In most cases the examples in the "Getting started" chapter are really simple but it only takes a moderatley complicated site to really see the the weaknesses and warts.

Re:how is this a book review?

[Anonymous Coward]

What is struts? Why it is better/different than JSP? How is better/different from XML/XSLT transformations?

RTFM, dumbass.

Re:Who still uses structs? Tapestry the way to go

[lukegalea1234]

I love tapestry.. I have tried struts and turbine and hated both.

They both were too concerned about making it easy to port existing jsp/servlet code to them and as such bring along so much crap for compatibility.

Also, the documentation for both struts and turbine are ridiculously bad compared to tapestry... and the turbine community is one of the least responsive I have ever had the displeasure of asking a question.

Overall, the experience of developing using Tapestry is much much better than the competition.

Tapestry is simpler and more powerful

[nikko]

For an example of Tapestry in action, look at

www.pixory.org

UI/Control was very easy to implement and contains very little custom logic.

Look at Tapestry on sourceforge

Re:Who still uses structs? Tapestry the way to go

[Mindbridge]

I have to disagree completely.

If you come from a Swing background, Tapestry is way more intuitive than Struts. You have components in both, and building your gui involves putting components in components, and finally into a frame (Swing) or a page (Tapestry). You don't have to care about how the JTable (Swing) or Table (Tapestry) components are implemented, you just follow the API and use them. I really don't see the similarity between this and JSP or Struts.

I think Tapestry is the only free Java framework out there that actually allows you to really build components rather than pages (as it is in most of the rest). You can build a component to edit the user preferences, for example, and it really does not matter which page or another component you put it in, how you put it in, and what the layout is. It IS Swing for the web.

It also has a lot of other things that are worth using, but for those check the Tapestry home page.

Re:Who still uses structs? Tapestry the way to go

[Anonymous Coward]

Tapestry Exception Reporting rules compares to the crud spewed out by JSP containers!

Don't think the Tapestry Demo server is expecting a /. attack so I won't put a link to an exmaple!

Re:"Just write it yourself" and "Perl! Perl! Perl!

[Vaulter]

You obviously don't know what struts is.

Struts is a set of server side components for implementing the MVC pattern, that come with some JSP tag libs as a convenience.

Struts can be used with Velocity. Velocity can only replace JSP, not struts.

FWIW, I love velocity as well. I use it in stand alone applications as well as web applications.

What about the bigger picture?

[smagoun]

Structs is cool, but it's just a small piece of a much bigger picture. There are many cases where a simple 1- or 2-tier app is perfectly adequate, and basing your app on Struts is appropriate for that. Those are rightly called "web applications."

If you're building an enterprise app, however, basing your app on Struts (or any other "web application" technology) isn't a good idea. Why? You wind up mixing your app's functionality with its implementation. Using an MVC framework like Struts alleviates this problem to a great deal, but when it comes down to it you still have a big pile of servlets that does everything from database access to presentation.

That approach isn't scalable, it's not adaptable to different technologies (there's a new webapp framework every week, it seems), it's not easy to integrate with other applications, and so on.

What's really needed is a way to define an application independently of the implementation details. Once you've defined the application, you can generate whatever interfaces it needs - like a Struts UI, an EJB persistence engine, etc. This is where my shameless plug begins: check out the Sandboss project for a way to define your enterprise app without being chained to a particular implementation detail like Struts or EJB.

While the techniques used in Sandboss are designed for the enterprise world, they're useful for web apps, too. I think it makes much more sense to over-engineer an application than it does to under-engineer it; overengineering takes more time up front but saves you 10x as much or more once development starts, since the well-don overengineered solution is more flexible and capable of responding to marketing's feature of the week. By picking Sandboss you get the best of both worlds - a robust framework where someone else has already done the engineering. You just define your app, and bam! Persistence, communication, control, the UI are all done for you.</shameless plug>

Re:What about the bigger picture?

[jaaron]

you still have a big pile of servlets that does everything from database access to presentation.

If you end up with a big pile of servlets like this then you aren't using the framework properly. No framework is going to save stupid developers with a bad design. It can try to save them from themselves, but ultimately, the developers have to have a clue about how to code and how to properly design an application.

Re:What about the bigger picture?

[smagoun]

If you end up with a big pile of servlets like this then you aren't using the framework properly

...which is why we need to keep building better frameworks. Struts attempts to point you in the right direction, but it's still fairly easy to abuse. Unfortunately, only a handful of the developers I've seen/heard/worked with actually have a clue on these things; most of them just want to get something built. Design is never a question in their mind - the only important thing is "what's easiest/what's fastest."

By choosing a more powerful framework, the consequences of such an approach can be mitigated. The key piece of a good framework IMHO is that the best way of doing things is also the easiest way of doing things. That way people looking to take the easy way out will wind up producing a better module than they would otherwise. Struts solves many of these problems, but it's still too easy to mush your application's functionality together with its implementation. The Struts doc even says something to the effect of "the obvious way is the easy way, but we don't recommend it." To me, that means the framework needs some help.

MVC on steroids: twisted.web.woven

[mesozoic]

Enough of that silly Java stuff.
Get Twisted.

Re:"Just write it yourself" and "Perl! Perl! Perl!

[thelexx]

I obviously didn't make any statements about what Struts is. All I said is that I prefer using Velocity. The reason is that I didn't/don't need the additional functionality that Struts offers. Jeez.

Some relevant links

[Paul Bain]

Struts is but one presentation framework. A discussion comparing Struts and other frameworks is informative, and, indeed, there is an entire website devoted to such a comparison. For Struts links, try the home page of Ted Husted, the lead Struts developer.

Re:Who still uses structs? Tapestry the way to go

[shredit]

You obviously spent about 6 minutes looking at tapestry. Using struts and tapestry extensively, I would definitely say that tapestry is much more mature. The whole point of web MVC frameworks to separate business logic from html. Every complex struts application I've every worked required scriptlet turds everywhere to get around the bentness of struts.

Step 1: define your requirements

[smagoun]

The first step in answering you question is to define your requirements. One the the [non]requirements you need is maintainability. That should play a big part in your implementation. If the app needs to be robust, maintainable, extensible, etc, you should approach it completely differently than you would if those weren't concerns.

That's where MVC comes in. It forces to you think about your implementation instead of blindly charging forward. That's overkill for some projects, but IMHO it's absolutely necessary for others (i.e. any project where more than about 2 people need to touch the code). Otherwise you wind up spending more and more time on maintenance/adding features.

FWIW, Slashdot uses more of the spaghetti pattern than anything else...

Re:Who still uses structs? Tapestry the way to go

[mobosplash]

I'm interested in Struts alternatives like Tapestry. Webwork and Barracuda are two others that look very interesting. Does anyone know if there is still any momentum with the other Jakarta framework, Turbine?

The main difference in these frameworks is how you handle the html. Struts is JSP focused, Barracuda uses XMLC and Tapestry uses HTML with extra tags, Webwork and Turbine use Velocity as a first choice and can use JSP.

I use Struts a lot now. The community is very active and helpful. There is more documentation available and with a lot of the development is by Sun insiders so I expect it to be around for a while. Unlike some, I see the JSP focus as an advantage in that it can easily include other tag libraries.

That said, I'd like to see people post advantages to other approaches. Not "Struts sucks, use XYZ!" but "XYZ is better when your site uses ABC and needs to DEF".

Struts vs WebObjects

[lamz]

How does Struts compare to Apple's WebObjects?

Re:Struts vs WebObjects

[kwerle]

We did a little comparison where I work (I'm a WODeveloper). The upshot is that struts looks like the best non-WO tech I've seen. There are a lot of similarities, as I recall, though the discussion was about half a year ago - about twice my memories half-life :-)

Re:Struts vs WebObjects

[Anonymous Coward]

That's an easy one. Many many people use Struts because it works well and is open source. Noone in particular uses WebObjects because it is too specialized and proprietary and frankly just doesn't work very well.

Re:Struts vs WebObjects

[TapestryDude]

Struts is light years behind WebObjects. Tapestry is "inspired" by WebObjects ... they are kissing cousins. Each has its own set of strengths and weaknesses. Tapestry does a little less magic for you and thus is a lot more scalable. Check it out

Re:Struts vs WebObjects

[tyrione]

Glad to see you were strong enough in character to be referenced as Anonymous Coward. Grow a pair and write a sound discussion next time.

Re:Struts vs WebObjects

[screamingPants]

I wish this ignorant motherf*cker left his name, but he's too chicken.

"Noone in particular uses WebObjects" because the majority of "developers" are like the idiotic jerkoff who left this message: too stupid to know his own arse from his dog's because he's got his head up one or the other.

Just because 'NSync is popular doesn't make them good, but there are millions of teenage girls who think they're the best band in the world. Popularity means NOTHING about quality.

WebObjects is definitely a niche technology, but only because it's on a higher plane. If you want to truly expand your horizons as a web developer, spend some time with it. It is COMPLETELY different to all other Web technologies, with the simple exception of Tapestry. Tapestry is a very nice, clean framework that is similar in mindset to WO. It's Open Source and it's free so stop wasting your time with Struts, which is a sad, pathetic piece of horse-pus, and elevate yourself out of the quagmire that you're wallowing in.

Also recommended...

[grommet_tdi]

...the video companion: "Sluts in Action"

This is actually a valid question

[jaaron]

It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?

This comes up from time to time and I think it's a good question. There was an good discussion about this on the jakarta-general mailing list. It's a long thread, but if you'd like you can start reading at this point. The best part of it I think is this response by Jon Scott Stevens:

Java is not the fastest technology to develop in, however, it produces the best code for the long term.

PHP is the fastest technology to develop in, however, it produces the crappiest code for the long term.

I develop Scarab in Java because it is going to live far longer than I do and needs a solid base to work from.

I develop my bar's website in PHP because I just needed to get the job done quickly and was not concerned with code quality.



Remember, PHP originally stood for Personal Homepage Parser. Java's web application technology was designed from the start to be a solution for a large "enterprise" class web site. You can do more with Java but you definitely take a hit in initial development time. Personally I feel that in the end, Java is easier to maintain and extend (but you may disagree).

By the way, Yahoo! didn't go with Java because of the Java threads implementation on FreeBSD. It didn't have anything to do with the merits of the java language. (See Why not JSP, Servlets, or J2EE?)

Re:Who still uses structs? Tapestry the way to go

[jaaron]

Velocity is still very much alive. Watch the mailing lists for a while if you want to see what's going on.

MVC Pros and Cons

[herwin]

MVC is great if you really have an application that needs to separate Model from the display windows (View) and mouse/keyboard (Controller). It ain't so great if any of the following are a concern:

1. Complexity of implementation
   
2. Modularity and decoupling
   
3. A distinction between domain model (the system of concern) and applications model (what people want to see).
   
4. Coupling between View and Controller.
   

Most programmers at least combine the View and Controller--Java supports this rather effectively--and some distinguish between domain and applications models (Visual Proxy pattern).

Re:MVC Pros and Cons

[Slashcrunch]

mouse/keyboard (Controller) MVC... umm... the C doesn't equate to keyboard or mouse. M = Model - business objects and such V = View - presentation, web pages etc. C = Controller - code, in this case a Servlet that decides what is to be done And now back to your coffee :)

Re:MVC Pros and Cons

[herwin]

Slashcrunch comments: "mouse/keyboard (Controller) MVC... umm... the C doesn't equate to keyboard or mouse. M = Model - business objects and such V = View - presentation, web pages etc. C = Controller - code, in this case a Servlet that decides what is to be done And now back to your coffee :)"

See this discussion of MVC, where it states "A controller offers facilities to change the state of the model." The idea back in the late 70s was to allow the computer user to select the most appropriate control interface to address his or her possible disabilities.

Re:Who still uses structs? Tapestry the way to go

[Anonymous Coward]

Web apps blow. Why spend twice as much time and effort developing an application just so it can have a crappy html interface. Wouldn't everyone like to use a gtk slashdot interface than this html junk!

CGI::Application

[chad_r]

Perl coders may also be interested in CGI::Application, for a similar MVC approach. I've done a few JSP apps which had a framework similar to Struts (too bad I didn't know about it beforehand), and now I hate to write perl CGI's in the unplanned, ad hoc way I used to do.

Re:Who still uses structs? Tapestry the way to go

[kschrader]

The Jakarta Turbine project still has plenty of momentum behind it. In fact, there's going to be a new realease of the Turbine framework within the next couple of days.

MVC???

[haystor]

Emacs is my controller.

Re:Who still uses structs? Tapestry the way to go

[bbqBrain]

It would be just as fair for me to say you've obviously spent about 6 minutes working with Struts. If there are a lot of scriptlets in the JSPs, something was designed poorly, and it isn't necessarily the framework. Any business logic should be in the action classes. Complex presentation logic should be in custom tags, which can accept parameters; they make very nice reusable components.

FWIW, I spend several weeks using Tapestry. I will admit, the bulk of my MVC experience is with Struts and not so much Swing or SmallTalk. Tapestry was definitely not my bag.

Pardon My Ignorance... what about JBoss?

[ovapositor]

I have yet to get involved with any of these projects. I hear a ton of press about how great JBoss is. Does using struts mean I don't need to wory about using something like JBoss?

Re:Pardon My Ignorance... what about JBoss?

[jkauzlar]

JBoss is an Enterprise JavaBeans container to be used for large to very-large applications and is purely in the 'controller' (or was it model? I forget :) segment of the MVC. Struts is great for implementing a simple run-of-the-mill to moderately complex web application and its purpose is to structure the application. JBoss provides no structure to the application as a whole, but acts as another layer in the structure. Struts and JBoss can work together without any problems whatsoever.

Re:Pardon My Ignorance... what about JBoss?

[Anonymous Coward]

Get a clue! Read about these projects before asking dumb questions!
Oh, I just bought a bike but I was just wondering, is that new blender something I could use instead? Oh, and what about my television? will it fly if I sit on it? Santa, help me!
you get the idea...

Fie on MVC

[scrytch]

> MVC is about projects that work well.

The M is fine, the V I have no problem with. It's the "C". Frankly I haven't seen a decent tutorial treatment of the awful mess that is the "controller". Is it business rules? Is it input events? Is it update events? Is it a mediator? Is it just everything that doesn't seem to fit in the other two categories? Everywhere I look to read up on MVC, I see a lot of handwaving about how it's God's Own Architecture, but aside from basic "duh factor" things like "decouple the view of the data from its underlying representation", I really have yet to see anything that gives a clean design for this mysterious "controller".

Doesn't help that MVC for widget sets has been abandoned for Morphic in Smalltalk, at least the research variant of it that Smalltalk's founders still follow.

Re:Fie on MVC

[thammoud]

I agree wholeheartedly with your comments. There is very little of how. Swing MVC in my opinion is a one very good way of implementing it.

I implement it this way:

1) The model knows nothing of the view or the controller. It must notify observers of state changes.

2) The view knows nothing about the controller. It simply displays values of a model into the appropriate fields.

3) The controller knows both the model and the view. It installs listeners on both and updates there state based on changes to either. For example, a user entering text in some field will cause the listener to validate and update the corresponding field on the model.

This has worked very well for us and leads to a neatly divided system where everything is pluggable.

Don't for get WebWork!

[Anonymous Coward]

another project for MVC is webwork! its great, its not tied to the web (as its name implies) and can use any view technology such as swing, velocity, jasper, jsp, xslt, you name it.
check it out at http://www.opensymphony.com/webwork/

Java WebStart helps alleviate this.

[l8apex]

Assuming you find the installation of the Java 1.4 browser plugin acceptable, WebStart offers a compelling "have your cake and eat it too" alternative to web based applications.

WebStart lets you write web based Java applications that automatically download, install and self upgrade. The initial installation make take some time, but the jar files are stored locally (unlike traditional applets). making subsequent launching and running much faster.

This ultimately allows you to use all of the traditional thick client benefits in a lightweight deployment mechanism.

For an example, check out the thinlet project. Look at their webstart-based demo of the Amazon.com web service catalog browser (lets you browse their database using their SOAP api).

Also notice how fast it is. Using this approach, you're only transmitting the API message and the resulting data, instead of that, the HTML/formatting, graphics, javascript over and over again.

I think technology like this is the future of web-based applications, not further extending a text formatting language like HTML to do web apps.

Re:Java WebStart helps alleviate this.

[TheLink]

How big is the plug in? How long to download over 30-50Kbps?

Hmm, this thinlet stuff actually looks thin :).

I remember a client's contractor trying to do this sort of thing years ago. Regular multimegabyte downloads due to bugs - in both Java and the apps.

I would have said it didn't work, but they seemed to have managed to adjust client expectations. It was for the client's clients tho, so I'm not sure how it really turned out in the end - I was there for the firewalls.

Re:Java WebStart helps alleviate this.

[l8apex]

the windows plugin can be downloaded from http://java.sun.com/getjava/.

It's about 8MB in size- On windows machines it installs automatically like other browser plugins.

What's nice is that this is a plugin maintained by Sun, not one of your own creation. You just write apps that leverage the technology. So far Sun's java WebStart works on windows, MacOS X, Solaris and Linux. Not too shabby!

Fat web clients == VB all over again

[Tablizer]

I have concluded that a typical GUI biz-form-and-grid application does NOT need large app-specific programming code (bytecodes nor EXE's) at the *client* end.

It is even possible to have zero Turing-complete application-specific code at the client side if security is key. However, even if client-side code helps the responsiveness, it should be *optional* in the protocol design.

I think something like SCGUI (my own pet) and XWT are the way to go. I hear Mozilla's XUL (sp?) is getting closer to these. JavaScript+DOM is a buggy hack, better suited for e-brochures rather than e-forms.

Java has proven too bloated for HTTP-friendly biz apps. If they kept the protocol lighter, then Sun and MS would not be sueing each other over this thing that has grown into the Java OS.

Most business logic should be on the *server*, not the client. Why does everybody keep gravitating toward fat clients when the web was supposed to reduce it?

Re:Fat web clients == VB all over again

[Anonymous Coward]

Most business logic should be on the *server*, not the client. Why does everybody keep gravitating toward fat clients when the web was supposed to reduce it?

Dude, Struts (and every other framework mentioned here) is browser-based (HTML + JavaScript).

Java fat-clients are dead, and have been for a while now.

Ironic: WebObjects has always been MVC

[tyrione]

I find it rather ironic when folks tout this as some sort of advancement in Appserver development since NeXT did it first and has it from the ground up in WOF and all their framework philosophy.

eBook availibility

[hfcs]

These folks seem to take eBook publishing seriously.

Dead tree ver. from publisher: $44.95 +s/h
eBook version from publisher: $22.47
Dead tree ver. from B.A.M. $33.49

Publisher site is here.

Re:Who still uses structs? Tapestry the way to go

[joib]

Who still uses structs?


Yeah, I sure do. They bolted some syntactic sugar on top of good old structs and now they are called classes instead.

PHP or Struts?

[Anonymous Coward]

Hey!
have you done an study or something like that.
PHP is an excellent tool and I use it, but to affirm that it is a better tool for whatever application is overly simplistic.

Perl? Just use PHP

[TheSync]

OK, I'm NOT a software engineer. That said...

How the heck can you keep up with all this dang Java stuff? "You can use Bluelegs to support CowBerries for n-tiered enterprise apps under COW2BITEME from a UML converter."

In the time it has taken me to read up on Application Servers, JSP, J2EE, beans, UML, struts, etc., I could have written about 20 PHP applications...or 20 .NET ones!

If Java is so cool, why is Yahoo moving to PHP?

All this structure to build what? Web apps move content from user to DB and back to user, occasionally doing some math in-between.

Then there is stability. 200 blades and a layer 4 switch, I say! Call me when more than 50 blow up.

I know this sounds like a troll, but what is the deal? Haven't there been enough books written?

Agreed in principle but...

[sleight]

... to speak for myself, I tend to work in environments where TTM (Time To Market) is crucial, the "team" tends to be me and maybe another engineer, completing the required feature set in the alotted (and fairly short) time span is mandatory, and maintability is placed on the sacrificial altar of needing everything and needing it yesterday.

Elegant design is a wonderful thing and, personally, I prefer to take my time, weigh my options, come up with a design, and attack. However, typically, most of that time I would like to be spending on design is usually better spent building the product and fufilling that feature set.

I can't say that I've spent a lot of time on Struts. I had a go at it on my last job for about six months. Ultimately, given the above constraints, I developed the perspective that for a product that will move through multiple maintainers hands, that will be around for a while, and will have to mature over time, it's wonderful. However, when you need your product written yesterday, Struts will just slow you down with all of the added abstractions that the architecture enforces.

Re:Agreed in principle but...

[mobosplash]

However, when you need your product written yesterday, Struts will just slow you down with all of the added abstractions that the architecture enforces.

I felt this way on the first couple of projects I used it on but now that I know my way around it I've changed my mind. Most of the things it does are things you're going to have to get to eventually so any time it wastes in the first week is more than made up in the later weeks.

The only thing I don't really get benefit from is the abstraction of error messages and labels into the applications.properties files. I'd like to just put the messages in the code. That's just because I never have i18n in any of my sites. Clients love it when we say that we can do it easily in the future though so maybe it's worth it for that.

Struts is...

[6Yankee]

...the soiled nappy of the bastard spawn of Satan.

Sure, the custom tags make your JSPs look sweet. But what a mess underneath. I think it was something like five or six hops from one file to the next for every request, coming back to the main struts-config.xml file at least twice. That file quickly becomes unmanageable in anything other than the Greatest XML Editor Ever (i.e., not JBuilder!), and I spent around half of my time scrolling through thousands of lines of near-identical XML looking for the bit I had to change.

There might come a point at which all this unnecessary complexity actually starts to make life easier - but it'd have to be one huge project.

Saw it, tried it, hated it, ran away.

True That

[crisco]

I bought one of the early Manning PDFs that was reviewed here on /. a couple of years back, good writing and convenient to be able to purchase an inexpensive yet quality piece of writing. Dead tree format is nicer but sometimes you gotta stay under budget while expanding that (virtual) bookshelf.

Oooohhhh, big-sounding word

[irritating environme]

MVC aka three-tier server aka thin-client aka dumb terminal - mainframeprogram - mainframedatabase When will people stop reinventing everything with a goddamn new-fangled term? Patterns are a nice abstraction, but the level to which people apply them is out of control. Once you've designed something, you can simplify the communication of the design by explaining its structure in patterns, but thumbing through a pattern book to find a design is just not the right way to approach things.

Re:Oooohhhh, big-sounding word

[Anonymous Coward]

Uh, MVC has nothing to do with three-tier servers or thin clients or dumb terminals. You don't know what the fuck you're talking about.

Re:Oooohhhh, big-sounding word

[irritating environme]

MVC *is* a three-tier architecture: Model = Database Server (3rd tier) View = Client Software (1st tier) Controller = Application Server (2nd tier)

Re:Who still uses structs? Tapestry the way to go

[TapestryDude]

That's strange, for me Tapestry is extremely natural, and you can accomplish a lot using very light touch.

Despite authoring Tapestry, I get to work with Struts (on a truly massive project) every day, and really hate it with a passion.

We are addressing some issues with adopting Tapestry ... these are being developed right now as "Tapestry Lite" and will appear in the 2.4 release. You'll be able to get simple applications up and running much easier (no app spec, no page spec, just the HTML page with funky attributes in some tags) and transition at your own pace to more traditional Tapestry or whatever mix is appropriate for your project. We're making the cost of entry to Tapestry low ... lower than JSPs, lower than Struts.

What handicaps most developers from other systems is that they try to map page-and-action development (Struts, particularily, or any other servlets and JSP) to Tapestry, which doesn't work. Apples and oranges.

Tapestry is about components, working together. The framework provides the basic services that allow you to build components of arbitrary complexity and hook them together easily while subtracting out loads of complexity.

Tapestry is doing all the busy work ... moving properties around, providing names for forms and form fields, validating input, processing requests, building URLs ... what you end up providing is the raw HTML templates, specifications to configure components, and small classes with short listener methods to handle user actions.

Meanwhile, the growing Tapestry team is giving us a real leg up ... I'm busy coding while Neil is working on a *much* improved tutorial and Mind Bridge and pals are coming up with big new components.

-- Howard Lewis Ship

Re:Who still uses structs? Tapestry the way to go

[TapestryDude]

Thanks! That was a key, early priority in Tapestry. Way back at servlet API 2.1 and JDK 1.2, Tapestry would still do a great job reporting exceptions (and still does). Tapestry uses a lot of nested exceptions, the exception reporter uses reflection to dynamically "dig out" nested exceptions, showing a stack of nested exceptions. Each exception is identified, along with message and any JavaBeans properties. The stack trace at the deepest level is displayed. In addition, full output of the various Servlet API objects is dumped out. I've had colleagues say that, everything else being equal, they would use Tapestry just for the exception reporting. The goal is to send the developer right the offending line without having to reproduce the problem using a debugger. Big time saver. Moral of the story: Tapestry is not demo ware, it is serious code developed by a serious coder for other serious coders.

struts and JavaServer Faces

[Anonymous Coward]

Don't now if they mention this topic or not in this book -
If you are currently using Struts 1.1, you should consider the upcoming changes to it vis-a-vis Sun's JavaServer Faces specification.

A recent and good introductory article about JSF is A First Look at JavaServer Faces

Craig McClanahan mentioned the transition to using JSP Faces in one of his Struts presentations at the recent ApacheCon and it has been discussed on the Struts mailing lists (e.g. http://www.mail-archive.com/struts-dev@jakarta.apa che.org/msg08457.html

Re:Perl? Just use PHP

[Anonymous Coward]

Yahoo is moving to PHP solely because they depend on FreeBSD servers, and Thread/Java support on FreeBSD is week at best. (Trust me, I'm at a job where i'm forced to deploy Java on FreeBSD).

If you've ever worked on an app for an IT Department that is rather large, you'll understand quickly why companies use a programming language instead of a scripting language. There are programming methodologies, frameworks, toolsets, and other advantages that make enterprise level application development in Java worthwhile.

PHP is great for small standalone apps when the problem domain is finite, and no legacy systems are involved.

When you need to integrate AS/400 systems, FileMaker databases and connect to credit card billing systems, you'll see that you'll go places that PHP can't take you.

I don't want to sound lame and say trust me, when you've done large-scale application development for an IT department of a good size company, you'll figure it out.... but that's really the case.

I use PHP apps like phpMyAdmin as a regular part of my development, but Java provides the discipline and legacy integration that scripting language can't provide.

deadtree vs. electronic bit version

[Anonymous Coward]

> Dead tree ver. from publisher: $44.95 +s/h
> eBook version from publisher: $22.47
> Dead tree ver. from B.A.M. $33.49
I'd point out that the eBook version requires a computer and electrical power to use = noxious chemical byproducts from computer production + air/power pollution from power plants. Not to mention that most people end up printing out most of the eBook pages ...

Think of a book as a long-lasting organic recording of ideas - one that will outlast any e-book.

Thanks!

[Anonymous Coward]

What I can say - thanks for the link!

Re:"Just write it yourself" and "Perl! Perl! Perl!

[mobosplash]

Struts can be used with Velocity. Velocity can only replace JSP, not struts.

I use Struts but I'm not clear on why you would use it without JSP. I think of the taglibs as half the product. It seems if you want to use Velocity or XML/XSLT you would use a framework more optimized to work with those like Webwork or Turbine.

Struts?

[BoxedFlame]

I have only heard bad things about struts in all the years of being a regular ops of #java. The way to go is webwork, available from www.opensymphony.com. It's small, it's intuitive, it's FLEXIBLE (very much unlike struts) and it's just plain good. Webwork supports several view technologies too, JSP, Velocity and VoiceML in the official distribution, although basic Swing support is available too. Writing support for your own favourite templating library could be done in a matter of hours.

Re:Who still uses structs? Tapestry the way to go

[shredit]

[bbqBrain said:] It would be just as fair for me to say you've obviously spent about 6 minutes working with Struts.

You are way off. I have used struts for over a year (and still do) and have been extremely active on the struts mailing lists. Struts has the right idea, but just doesn't provide the same value.

[bbqBrain said:] If there are a lot of scriptlets in the JSPs, something was designed poorly, and it isn't necessarily the framework. Any business logic should be in the action classes. Complex presentation logic should be in custom tags, which can accept parameters; they make very nice reusable components

So, I'm guessing your solution is to use custom tag libraries over scriptlets, right? The only thing lamer than having scriptlets in your JSP files is compiling html into tag libraries. Any complex presentation logic will require you to hardcode html in your java source, no matter how many parameters you pass into a tag. Kinda defeats the purpose of MVC, doesn't it?

Here are the things off the top of my head that need improvement with struts:
-The way ActionForms work and the game you have to play copying values from JavaBeans to FormBeans and vice-versa.
-Poorly named conditional tags like "present" and "notPresent". What does that mean? Empty? Null?
-The logic:iterate tag can't handle nested repetitions. An additional nested tag is required.
-No page wrapping components that allow you to insert page body content. (Tiles won't help you here either)
-There is no equivalent to tapestry's 'rewind' features. You have to re-inflated objects your interested in on every request, which is sooo cumbersome.
-All of the really good struts features are in version 1.1b. Which seems like it will be in beta forever.

Re:Who still uses structs? Tapestry the way to go

[Allthefuckinggoodnam]

-All of the really good struts features are in version 1.1b. Which seems like it will be in beta forever. I'm glad I read your entire post, because I was getting ready to reply that you should look at 1.1 and the JSTL core and format taglibs. I'm very curious about Tapestry, and I am going to spend some time looking at it (never have even heard of it before, but I've been working with struts for the past year and a half fairly extensively). Is there any particular resource you can recommend for a struts veteran who is interested in learning about tapestry?

Re:Who still uses structs? Tapestry the way to go

[Allthefuckinggoodnam]

sh$t, sorry about the bungled formatting....

i'll try again:

----All of the really good struts features are in version 1.1b. Which seems like it will be in beta forever.

I'm glad I read your entire post, because I was getting ready to reply that you should look at 1.1 and the JSTL core and format taglibs. I'm very curious about Tapestry, and I am going to spend some time looking at it (never have even heard of it before, but I've been working with struts for the past year and a half fairly extensively). Is there any particular resource you can recommend for a struts veteran who is interested in learning about tapestry?

Explanation and histories...

[Stu Charlton]

The best explanation of MVC from a "systems" perspective is in Buschmann et al's Pattern Oriented Software Architecture Vol 1: A System of Patterns, which explains "Presentation-Abstraction-Control (PAC)".

The real reason MVC never has been explained the way PARC envisioned it is that no other Smalltalk implementation actually USED pure MVC. Original MVC used to imply that the controller was the code that handled the user input. Eventually this just got embedded into the widgets themselved -- most commercial Smalltalk implementations combined the View and the Controller together.

Now on a larger framework level, the spirit of MVC prevailed but evolved the controller into either a layer of event handlers (the Mediator approach) or a rich declarative binding model (the AspectAdaptor/ApplicationModel approach taken by VisualWorks).

From my perspective, Struts tends to embody the VisualWorks approach pretty well for web applications, with some minor thorny problems intrinsic to web development that haven't really been solved effectively yet: validation, distinction between "client model" and "business object model", and dependencies on the web request-response lifecycle (i.e. scopes of variables are tied to requests or sessions).

Struts, WebLogic and TOPLink = WebObjects

[Stu Charlton]

Only $25k more expensive :D

Struts is the real deal

[Stu Charlton]

Struts turns web screen flow & actions into potentially reusable state machines. It enables quick validation of forms, tremendous flexbility in how you wish to actually code your application's logic -- in stored procedures, in basic Java procedures, or a fully blown object model.

The popularity of Struts can be attributed to many things

- It's what most projects would write themselves anyway
- The source code is extremely clean.
- It is very simple
- It really helps speed maintenance

For me, Struts is the first embodiment of the potential exhibited by Apple's WebObjects Framework. Struts still has a ways to go to get there, but it's getting there fast. Combined with an object/relational framework, we may finally have in 2003 what WebObjects offered in 1996 :D

ASP.NET also exhibits a lot of this potential, and IMHO you can't hope for J2EE to compete with the productivity of ASP.NET without an MVC framework like Struts. I really hope Sun realizes this, fast. JavaServer Faces is long, long over due. And if ADO.NET ObjectSpaces gets released, the Sun may have to stop treating JDO as a second class citzen, fast.

Re:Struts is the real deal

[screamingPants]

You're right. Java can't compete with ASP.NET with an MVC framework. However, STRUTS IS NOT THE ANSWER. It is dopey and poorly-designed and has "amateur" written all over it.

It's not even CLOSE to where WO was in 1996... sadly. But RIGHT NOW you can get Tapestry, for FREE, for all your J2EE creamy goodness, from http://tapestry.sourceforge.net and you can *almost* catch up to WO. In in some cases, even pass it.

Just because there are books about Struts doesn't mean it's a good tool. There are plenty of books about VBScript, after all.

Re:Struts is the real deal

[Stu Charlton]

"However, STRUTS IS NOT THE ANSWER. It is dopey and poorly-designed and has "amateur" written all over it."

I'm saddened your snobbish attitude. You do both yourself AND Tapestry a great disservice.

Struts may not be appropriate for absolutely every class of web applications. But to suggest it is poorly designed by "amateurs" does not reflect the character of Craig MacLanahan, Ted Husted, David Winderfeldt, and many of the other maintainers, all of which are professional software developers with combined decades of experience.

Re:Struts is the real deal

[screamingPants]

I am not suggesting that it was designed by amateurs, I am stating it.

It smacks of the same kind of lameness that permeates the entire JDK.

I doubt it

[Anonymous Coward]

Struts sucks for numerous reasons:
- XML galore / brittle architecture: config issues are 80% of your problems. Read the Struts mailing list, it's pathetic.
- namespace overkill: mapping between Form beans, actions, serialization beans is horrendous.
- overengineered for even the simplest things: (~100 lines of code to lookup a resource string. True! read the source...).
- slow: heavy usage of Taglibs & Reflection APIs
- still JSP-based (he he... the monster doesn't go away...). Who said an HTTP server has to be a JSP container?
- doesn't work well in a team environment as a simple screen is usually scattered accross at least 5 (or more) files: tile(s), action, component, Java Form, Action code, etc.
- far from a RAD tool

There are lots of other frameworks out there. The pletora of new Struts books soon coming out won't change the fact that Struts is a sucky environment. So go ahead, buy the book and see how long it takes you to code a simple app. You'll be out shopping for a new framework in a heartbeat.

Virtual mod point to you

[GCP]

Interesting. I don't have any experience with Python, but having used many, many other platforms over the years, I know how much one's opinion about a tool can change after a year or so of intense effort. I'm always interested to hear from those who have gone through it, especially when the whole team eventually reached the same conclusion (as usually happens, in my experience).

Bureaucracy has its downsides too

[Anonymous Coward]

geez.... I see the point in all the "architecture" and "design"...

But ultimately... it's just a bloody web-app..

Sure, other people need to maintain it and if the structure is not there they might mess things up. but then other people ALWAYS mess your shit up. No matter the "paradigm" or "architecture" or language...

I understand the need for strictness and structure... But often it is as much an emotional need as an actual technical requirement... You might know the saying that politics in academe are so vicious because there is so little at stake... I feel that something similar applies to web dev...

That is, because programming for the web is so messy, web programmers feel the need to get really fussy and professional about everything.. and they slam eachother over the head with books like these to prove they're right ...

I know of more than one project which concentrated on getting "the architecture" right for so long that the company folded before it ever shipped.. I know of numerous projects that spent ages getting "the architecture" right but now that it finally works and everything has been tested nobody dares make the three-line fix to make the damn thing work properly with Netscape 6.1...

So yeah do your best and try to design as much as possible... and you need to be a little uptight or things just spiral out of control... But don't confuse "Nobody can touch me because I've built a fortress out of requirements documents, technical specifications and legal waivers" with solid engineering...

Re:Perl? Just use PHP

[Anonymous Coward]

FileMaker databases and connect to credit card billing systems, you'll see that you'll go places that PHP can't take you.
As someone who uses FileMaker db's, data from a DB2 database on an AS/400, and does credit card billing with PHP (through CCVS), I'll have to disagree with you ;). Just look through all of the available libraries for PHP. PHP is about legacy integration.

Totally agree

[MosesJones]

That article was woeful
"Get and set are evil"

Set should always perform validity checking but is a mirror of the real world.

Take a watch, you "get the time" from the watch and are able to "set the time" of the watch. The watch then tracks the time. Some of the comments are fine, some are indicative of someone who thinks they _really_ know OO but in fact just hasn't thought it over properly.

Unguarded sets are bad, but gets are standard object functions in the real-world. You "get the speed" from your dashboard, you don't "set" the speed on the dashboard you press the peddle, which has the resultant effect.

Problem with MVC pattern

[Anonymous Coward]

i never understood why they have this controller thing between the Document and the view.

(yes, so that you can swap views, documents, and so that document and views don't know much about the other).

But why should one need this? In practice you have
a situation where document and view are coupled by
the data/events that are exchanged between them.

I think Document View is a sound architecture.

MFC uses Document View - I think that was a good
idea.

Re:"Just write it yourself" and "Perl! Perl! Perl!

[thusted]

Velocity and Struts work very well together. Chapter 17 of Struts in Action is devoted to migrating a small application from Struts JSP to Struts Velocity.

-Ted.