Discussions

News: Soap Box: Software Fashion

  1. Soap Box: Software Fashion (77 messages)

    An interesting article from Software Reality about fashion in software. The authors compare the fashion world to the software world, and see similarities. They claim that hyper results in "Inappropriate Use of Technology", and ends up with "Stupid Fashion Victims". The case studies they use are: VB.Net, Struts, and XP... and I am sure they could have thought of many more.

    "Software fashions come and go, but they always claim a few victims on the way. Where there's fashion, you'll find that rather weak willed person who is the Stupid Fashion Victim (or the SFV for short). This article from Software Reality is all about fashion in software."

    We (the TSS community) are even quoted:

    "Software fashions get their own little forums on websites such as Javalobby and TheServerSide (TSS), and often invoke religious arguments about the scope of the application of the technology."

    Read Software Fashion

    Threaded Messages (77)

  2. Soap Box: Software Fashion[ Go to top ]

    "Stupid Fashion Victims"? Sounds like a lot of the zealots who pontificate at this site.
  3. Just one comment about Struts...[ Go to top ]

    I use it to control and define workflow, and am happy to embed little scriptlets in my JSP pages - since developer time is more expensive than graphic/html design time, I'm happy to reduce the complexity of the underlying code at the expense of increasing the complexity of html.

    I have a visual editor (IDEA from IntelliJ) that tells the presentation developer when they mess up the syntax. It is easy to envision a world in which presentation developers, many of whom are already familiar with JavaScript, are able to read, comprehend, and even write scriptlets.

    The struts Taglibs bring a huge learning curve, and the structure and deployment model of struts, coupled with the XML configuration, makes the entire project deployment model more complex.

    Best,

    John C. Dale
    Down in the Desert
  4. Somewhat unfair mention of TSS[ Go to top ]

    I thought the inclusion of TSS as a "fanboy" site was a little unfair. TSS does try to be somewhat even handed. However I could not agree more about struts - its out of hand - its raison d'etre has been exceeded and is now a complex beast that is powerful and unwieldy. My opinion.
  5. Not a very credible article[ Go to top ]

    Sounds like a typical rant from some frustrated techies, meandering through XP, XML, Web Services, EJBs, JSPs, Struts, VB.Net, etc. in a single "breath". I guess under this schema, COBOL is given more credit because IBM forced it down everyone's throat for 20 years.

    Open systems naturally allow for more experimentation. I thought that singling out Struts as a fashion seemed particularly unfair. MVC has been around for a long time. In the Java world, there are dozens of MVC frameworks. Just because Struts is beginning to take a mindshare position among vendors (BEA, IBM, Oracle, etc.), doesn't mean that the concept of MVC is rubbish. A framework for J2EE programming is essential for all but the simplest applications. Now there are tools appearing to make the use of Struts as that framework easier (read: hide the XML config files). I wonder if we could get them to install WebLogic Workshop, they would change their minds.... ;-)
  6. Not a very credible article[ Go to top ]

    "I thought that singling out Struts as a fashion seemed particularly unfair. MVC has been around for a long time. In the Java world, there are dozens of MVC frameworks. Just because Struts is beginning to take a mindshare position among vendors (BEA, IBM, Oracle, etc.), doesn't mean that the concept of MVC is rubbish. A framework for J2EE programming is essential for all but the simplest applications. "

    That is a great comment.

    How small does a project have to be before I will NOT use a well establish framework like Struts (or others) and use bare bones JSP?

    Struts was there when we needed it to be.
  7. ¡Complex problems or long term projects needs usually complex technologies!, the problem is not complexity but if it is used in a correct way.

      Ok, a few projects are not complex enough and we don´t need world-class technology. However it is very usual that many projects start as small projects, and became a very complex nightmare, and usually too, a good pattern refactoring and improving of technologies is not made.

      Moral: build your software as though it is your house, use good materials, good technologies (not bargain), a good foundation ...

     ¡ but use tiles on the roof not on walls !
  8. Great Article - talks straight[ Go to top ]

    EJB is a overkill - we all learnt by now ( yeah - except a few cases, where still a good MVC design can fit )

    XP - it was never a big thing - it caught up some steam but lost it in no time

    VB.Net- No clear migration path from vb to vb.net tells us how complex it must be

    Thanks for the Article TSS.
  9. re XP[ Go to top ]

    The article reminded me of a project I worked on for a now defunct software development company. Some of the project members worked out of state....they were consumed by process. I was consumed with getting the sork done on time, on budget, and as high quality as possible. The out-of-state-ers were inistent that test be written before the code. I relented and let them do it their way. My team and I just wrote code, then tested.
    By the time acceptance testing was to be started my team was finished, minus a handful of small bugs.
    The other team was only about 20% done. But they had their tests written.

    By the way, their tests were buggy! When do the tests get tested? Are the test tests written before the tests? Ad infinitum.
  10. re XP[ Go to top ]

    The out-of-state-ers were inistent that test be written before the code. I relented and let them do it their way. My team and I just wrote code, then tested.

    In my experience, unit testing is very important. I typically write these tests along with my code (not necessarily before), because it is easy (when sticking to mostly JavaBeans), catches some important errors early on, and helps keep my class API coherent. It also helps ensure my stuff works before I integrate it with other code. Writing unit tests after code is complete is not a good idea, because it is the surest way for testing not getting done (due to schedule pressures, laziness, and the difficulty of retroffiting bad code to be testable). Do you unit test at all? If not, I would hate being forced to maintain your code...

    Things like unit testing can be hyped beyond reason, but that's no reason to throw this valuable practice out the window. Learning how to use something correctly is the first step to using it effectively.

    Bill Willis
    PatternsCentral
  11. re XP[ Go to top ]

    We tested as we wrote the code - not waiting until after all the code was written.

    "I would hate being forced to maintain your code... "

    I would hate to maintain my code, or anyone else's code for that matter. Maintenance is boring.
  12. The out-of-state-ers were inistent that test be written before the code.

    ...
    > The other team was only about 20% done. But they had their tests written.
    ...
    > By the way, their tests were buggy! When do the tests get tested?
    > Are the test tests written before the tests? Ad infinitum.

    Well, it is quite stupid to write all unit-tests before writing the code.
    It's like BDUF and not agile at all.

    The "right" way to write unit tests before code is to write a simple test, implement the tested chunk of funtionality, test and move along. In this way your unit-tests work like scaffolding for your code. The tests test the code, and the code tests the tests.

    The benefit form writing unit-tests before the code (or along with it), is not only a test suite for regression testing, but also better designed code, with fewer dependencies and simpler interfaces.
  13. I'd agree. They certain weren't using anything remotely resembling XP.
  14. Soap Box: Software Fashion[ Go to top ]

    I am surprised that this is still news to anyone ... "There are no silver bullets" is as true now as it was 30 years.

    I am just as surprised at the opposite effect: I have seen a number of IT professional that learn that a particular technology won't solve every conceivable problem, and then flip-flop to the opposite side and decide that a technology is completely useless.

    I am heard a number of otherwise intelligent people say thing like "XML is not a magical tool that will automatically integrate all of my application data. Therefore, XML must be completely unless." (Replace XML with your fad technology of choice). It is the nature of software technology to fit into niches; the trick is to figure out what niches your application needs, what technology fill those niches, and which niches are empty (and therefore require custom development).
  15. Last nail in Struts[ Go to top ]

    I would really like Struts proponents to take the authors' challenge and explain to us what are the real benefits of this framework. I myself have a number of years under my belt of developing complex infrastructure and business frameworks, yet was never able to grasp what type of a problem is Struts proposing to solve.

    Yes, the Struts-heads incessantly trumpet how important it is to separate business logic from the presentation etc., but my question is -- why is it so important? And, if it is that important, why do we need Struts to do that? Why can't we simply organize our code in a carefull fashion, so as to avoid mixing business logic with presentation. It is perfectly possible to do that, using frameworks such as Webmacro, Velocity, etc. etc.

    I am a proponent of those templating frameworks, and I also know how to emulate their functionality using plain old JSP, but I just don't understand what is it that Struts offers that cannot be done in Velocity?

    To me, Struts is a propellerhead product developed by propellerheads for propellerheads. Since I'm not a propellerhead, I'm totally lost on the allure of that unnecessarily complex and horrendous product. It's like if the cars were built by car enhusiasts for car enhusiasts, it would probably take a lot of intricate ritual to even start the engine. Luckily, because today's cars are built for non-mechanically inclined general public, all it takes to start the engine is to turn the key.

    But, for the die-hard hobbyists, simply turning the key to start the engine is sacrilegious, since for them it sucks all the fun out of owning a car.

    Similar thing seems to be happening with the Struts followers -- they seem to wallow in unnecessary complexity, in maintaining those countless, pointless XML configuration files which are merrily scattered around the forest of folders with stupid names. Note to the Struts creators: how about giving us the equivalent of a turn-key approach? Have you ever stopped to think that maybe not all people take exquisite pleasure in tweaking those idiotic XML configuration files? How about giving us a unified view of all those parameters, hiding their actual location and implementation? Do we really need to know that the configuration parameters are stored as XML?

    Would it be too much to ask of you to put a more humane face on your product?
  16. Last nail in Struts[ Go to top ]

    I would really like Struts proponents to take the authors' challenge and explain to us what are the real benefits of this framework. I myself have a number of years under my belt of developing complex infrastructure and business frameworks, yet was never able to grasp what type of a problem is Struts proposing to solve.


    Glad to hear others feel the same way I do. When Struts came out, it looked like it was going to standardize the "Model 2" approach to J2EE web sites - controller servlet, command dispatching, etc. However, it seems to have gathered a *lot* of bloat. For most of the work I have done, using Struts does not seem to have that big of a payoff for all of the crap you have to deal with.

    I really wish another framework (e.g. WebWork2, Tapestry, etc) would reach critical mass and push Struts off the top of the web framework heap. By that, I mean I wish another framework would gain enough popularity to warrant several books (there are at least five Struts books!), good forums/wikis, etc. I would really like to investigate alternatives, I just don't have time/patience to deal with projects that have potential but awful docs/community support, like WebWork.

    On another note, XP *does* appear to have lost some stream. Certain practices are just too much to ask the majority of the community to adopt - namely pair programming. However, XP is certainly not dead and I think XP and their ilk swung the process pedulum in the much needed agile direction. More people are starting to realize that you don't need hard and fast requirements and design docs to develop software. Requirements change. Designs emerge as you discover nuances in the business that just aren't uncovered in the first pass. It appears that software methodologies have become more "agile" overall, and we have XP to thank for that.

    Ryan
  17. Last nail in Struts[ Go to top ]

    More people are starting to realize that you don't need hard and fast requirements and design docs to develop software.


    Huh??? Wasn't that how things have been since the day one? Or am I missing something? I thought that the biggest problem has always been the fact that people tend to believe that you don't need hard and fast requirements and design docs to develop software. Nine out of ten software projects that I was involved in had no design documentation (some of them got one as an after thought, after the product had been delivered).

    However, saying that that's a good thing worries me, as it gives free reigns to the already severely undisciplined software developers to go berserk. Developing software without understanding what the product is supposed to deliver is a surefire recipe for disaster. If that's what agile methodologies are advocating, then they are a bunch of crooks.

    I certainly hope you'll reconsider what you wrote there.
  18. Last nail in Struts[ Go to top ]

    Perhaps I should clarify...

    Several years ago I worked at a large telecom company and the process there was *very* heavy. There were several people *only job* was to gather requirements from the the in-house users and draft massive use case documents. Very Office Space - "I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that?! What the hell is wrong with you people?!"

    Anyway, I began work there as this part in the process was wrapping up. We were supposed to develop the application based on these use cases. We never spoke directly to the user - that's what the requirements team was for. Clearly, this bogged down development communication severly. Long story short - trying to get every last detail of the requirements before beginning designing, and then trying to get every last detail in the the design spec before coding was insane. Not letting us talk to the user directly exacerbated this problem. Because guess what - the requirements will change anyway! Then your "perfect" design is f'ed, and your code based on the perfect design is f'ed.

    My original point was that XP injected some reality into these stunted heavy-weight processes. Requirements *always* change. You will *never* have all of the requirements. Designs emerge. You will *never* have the perfect design up front. I think XP recognizes this reality and suggests some activities to help cope with this reality. Constant refactoring to keep code as lean as possible so that you can adapt to change. There are plenty more (constant communication directly with customer, simple design, small releases).

    The whole point of software development is to give the customer what they need. *They* define what they need. If what they need changes (or if what they originally told you what they need isn't *really* what they need), *we* must be able to adapt. XP aknowledges this truth and tries to provide a process to enable this. Whether everything with XP is right - that is up the individual (afterall, it is extreme). Either way, I think it nudged the software development process as a whole in the right direction.

    Ryan
  19. Last nail in Struts[ Go to top ]

    Ryan Breidenbach wrote on October 08, 2003 @ 08:35 AM:
    >Because guess what - the requirements will change anyway!

    Sorry (and please don't take this personally), but I simply couldn't disagree more with everything you wrote in your post. I think you're especially wrong in perpetuating the biggest myth in the software development industry -- that the requirements will change anyway. Let me explain:

    It is a fact that all of us have experienced the elusive nature of requirements, which apparently causes them to change incessantly. Just when we thought that we've finally nailed those pesky requirements, the users turn around and inform us that, no, actually, they don't want that, they want something else. So, on the surface, seems like you're completely right.

    But if we look into it more carefully, we'll see that something else is at play there. Imagine, as an illustration, that you hire some contractors to build you a gate at the entrance of your property. They gather the requirements, write up a proposal in their mumbo-jumbo techie speak, you fugure they must know what they're talking about and agree on the hourly rate and sign it off. They start working on the product, and three weeks later show you the beautifull fence they've built around your property. Annoyed, you tell them that that's not what you needed, and redirect them to build you a gate, and to forget about the fence. They comply, and a month later call you in to show you a sturdy little shack they've built in your back yard. By now, you're fuming, and cannot resist but badmouth those lousy contractors behind their backs, calling them lazy idiots. Eventually, you cut your losses and the entire project gets ditched.

    The above fictitious example illustrates, in a comically exaggerated manner, how non-IT side of the business views us IT guys. Fundamentally, it's easy to see that there is a serious miscommunication occuring between the business and the IT. They speak different languages. Because of that, the requirements cannot help but keep changing.

    We (the IT guys) get to be mightily annoyed by the businesses who keep changing their minds every two weeks. The non-IT guys, on the other hand, get to be as equally annoyed by us, who cannot comprehend that they need a gate, and instead we keep building them fences, shacks, roofs, etc.

    However, in my experience, when the two sides happen to speak the same language, the requirements all of a sudden, as if by magic, cease to change.

    I've been involved in projects where we were lucky enough to 'nail' those requirements from the very outset. We somehow managed to speak the same language as our customers. And, wouldn't you know it, once the product was delivered, the requirements never ever changed. The customers liked it, started using it, and never called us back to ask for any modifications.

    So, the much dreaded 'maintenance phase' is also a myth, perpetuated by the fundamental misunderstanding. Of course, if you have been unable to truly meet your customer's expectations, the customer will be forced to take the half-baked product and then keep bugging you for modifications, in the hopes that these modifications will eventually hit the mark and deliver on the expectations. But if the expectations have been met initially, there is nothing else to add. There is no maintenance.

    I've delivered products that were designed in such fashion that they fully satisfied customers' needs. One product I've built in 1996 is still in production, in pristine condition, untouched in the last 7 years, working like a charm around the clock. No maintenance, no enhancements, no nothing. How come? Magic? No. Simply put, my customer had certain goals that this product helps fulfill, and the customer is happy with it. The requirements were happily put to sleep once the product was delivered, which left us free to devote our efforts to conquering new territories.

    So, this whole mumbo-jumbo about 'agile' this and 'agile' that is a bunch of balloney. Of course, if you screw up from the very outset, you'll need an agile approach to avoid the shit hitting the fan, but that's just a sad, reactionary evasive tactics. Nothing good will ever come out of that. Instead, try facing the issue head on, be proactive, nail what is it that the customers are really trying to accomplish, and once you deliver that, everything comes to a standstill. Then, who the hell needs to be agile?

    Alex
  20. Last nail in Struts[ Go to top ]

    <Alex>
    However, in my experience, when the two sides happen to speak the same language, the requirements all of a sudden, as if by magic, cease to change.
    </Alex>

    I agree, if you both speak the same language, communication is bound to improve. This does not address everything though. For example, the project I am on now is to develop a web based application to be used by retail store managers to replace a manual, time entensive scheduling process. The nice thing is that this scheduling process itself is in place - they *know* what the requirements are. We have met with them about what they need *and* met several times after that to clarify some questions.

    However, *they* are the domain experts. *They* have been working in store operations. *We* are learning *their* business. Sure, we can ask all the questions we come accross. But chances are, some business processes will not be uncovered for whatever reason. They forget to tell us. They made some assumptions about our knowledge. Whatever the reason, new/changed requirement will probably surface during development.

    With this (IMO opinion very valid assumption) we chose to take the requirements we have, design, and begin development. We are confident that when we meet the current requirements, we will have a piece of software fit for production. My experience has told me that they will say, "Wow this looks great. I can't wait to show this to the rest of our store managers. But it would be really great if...". That "if" is what I am talking about.

    In this situation, we can take the approach of saying "Screw you, we built the freakin' application you wanted. No more requirements!!!" I prefer to say, "Well, we can release this now, and have an upgrade in a month. Or, we can take your suggestions back and work them into the initial release. Your call."

    <Alex>
    So, the much dreaded 'maintenance phase' is also a myth, perpetuated by the fundamental misunderstanding.
    </Alex>

    I don't have the luxury of working on software that I write, release and forget. Our customers want to add features to existing software. Crazy, huh?

    <Alex>
    So, this whole mumbo-jumbo about 'agile' this and 'agile' that is a bunch of balloney. Of course, if you screw up from the very outset, you'll need an agile approach to avoid the shit hitting the fan, but that's just a sad, reactionary evasive tactics. Nothing good will ever come out of that. Instead, try facing the issue head on, be proactive, nail what is it that the customers are really trying to accomplish, and once you deliver that, everything comes to a standstill. Then, who the hell needs to be agile?
    </Alex>

    Well, when you throw words around like "mumbo-jumbo" and "balloney", you must be right. I guess we just live in two realities. I live in the one where our users and their requirements aren't perfect and our software has a full life-cycle, including upgrades *and* bug fixes. You live in a world where you nail requirements the first time around everytime, your software never has bugs, and you never upgrade anything. Cool. Want to trade?

    Ryan
  21. Nailing the end users' goals[ Go to top ]

    <Ryan>
    With this (IMO opinion very valid assumption) we chose to take the requirements we have, design, and begin development. We are confident that when we meet the current requirements, we will have a piece of software fit for production. My experience has told me that they will say, "Wow this looks great. I can't wait to show this to the rest of our store managers. But it would be really great if...". That "if" is what I am talking about.
    </Ryan>

    OK, here's an infallible tip -- as soon as you encounter that "if", you know for sure that you haven't understood the real needs/goals of your customers. If you manage to understand and truly nail what is it they are really trying to do, trust me, no "ifs" will raise their ugly head. I've been through that, and I've seen with my own eyes that it works that way.

    <Ryon>
    In this situation, we can take the approach of saying "Screw you, we built the freakin' application you wanted. No more requirements!!!" I prefer to say, "Well, we can release this now, and have an upgrade in a month. Or, we can take your suggestions back and work them into the initial release. Your call."
    </Ryon>

    And that's where the real trouble begins. Instead of going back to the drawing board and trying to rectify your initial misunderstanding of their goals, you decide to fish for results, to build things more-or-less blindly, following some feeble clues from your customers, and then throw the modified product against the wall to see if it will stick this time around.

    You'd be in for a long, unpleasant haul if you adopt that approach.

    <Ryon>
    I don't have the luxury of working on software that I write, release and forget. Our customers want to add features to existing software. Crazy, huh?
    </Ryon>

    Not really. The customers always want to add features to the products that don't meet their expectations. If the products meet their expectations, what's to add?

    If say my expectation is to go out and buy me a car that will take me around the town in a safe, affordable and comfortable fashion, and if I manage to purchase such a car, why would I ever need to add any features to it? If, on the other hand, the car tends to fall short of delivering the goods, I would be frantically shopping around, asking questions, trying to add some feature that would fix the unbearable situation (or, I'd be asking for my money back).

    <Ryon>
    I guess we just live in two realities. I live in the one where our users and their requirements aren't perfect and our software has a full life-cycle, including upgrades *and* bug fixes. You live in a world where you nail requirements the first time around everytime, your software never has bugs, and you never upgrade anything. Cool. Want to trade?
    </Ryon>

    You're right -- we do live in two realities. And, no, thanks, I don't want to trade with you. I have formed a firm opinion that it's no fun spinning my wheels.

    Just to clarify certain things -- our software does have some bugs, but nothing of catastrophic proportions. It's no major upheaval fixing those bugs.

    As for the upgrades, because we use Java, it pretty much runs anywhere without the need for upgrading.

    There may come a time, of course, when the business practices change so drastically that the existing application ceases to be usefull. When such thing occurs (very rarely, mind you), my approach is to build the new solution from scratch, rather than try to salvage the existing code. I never try to build an application that will be all things to all people (I don't believe in the 'one size fits all' approach).

    Needless to say, I'm not big on the code reuse craze either. I think each problem domain must have its own dedicated tailored code base. There is no sense in sharing that promiscuously with other domains. But, that's just me.

    Alex
  22. Nailing the end users' goals[ Go to top ]

    [Alex B stuff on 100% customer satisfaction]

    Please tell me where you work. I've been in the biz for 14 years and worked for many companies in a consulting and perm fashion, and I've never seen any one nail a project the way you've described, or users who were so satisfied with the result that they wanted no changes. You must be either in an incredibly static business, being writing very, very simple stuff, or are disconnected from your users to an extent that you don't hear what they're saying.

    The picture you paint just does not match any reality in any business I've ever worked in. Software projects just don't work that way.

        -Mike
  23. Nailing the end users' goals[ Go to top ]

    <Mike>
    Please tell me where you work. I've been in the biz for 14 years and worked for many companies in a consulting and perm fashion, and I've never seen any one nail a project the way you've described, or users who were so satisfied with the result that they wanted no changes. You must be either in an incredibly static business, being writing very, very simple stuff, or are disconnected from your users to an extent that you don't hear what they're saying.

    The picture you paint just does not match any reality in any business I've ever worked in. Software projects just don't work that way.
    </Mike>

    Seems like a lot of people on this forum come from a very abusive and dysfunctional environments, where they get bruised daily by incoherent practices. That doesn't surprise me, as I too have been exposed to many such abusive situations and places in this industry.

    However, just because that seems to be the norm for most people, it doesn't automatically mean that the non-abusive practices simply don't exists, or could never ever exist, period. Which is what you seem to be saying.

    I was fortunate enough to work in environments where we managed to get our act together, to elevate ourselves beyond the incoherent abusive lurching from post to post. I relate my experiences here in a positive fashion, and all you have to say is 'get out of here'! You are shooting yourself in the foot by refusing to listen to some potentially usefull pointers and tips from the real life trenches. You remind me of those people who plug their ears and walk around shouting 'la-la-la-la!'

    Suit yourself.

    Alex
  24. Nailing the end users' goals[ Go to top ]

    \Alex B\
    Seems like a lot of people on this forum come from a very abusive and dysfunctional environments, where they get bruised daily by incoherent practices. That doesn't surprise me, as I too have been exposed to many such abusive situations and places in this industry.
    \Alex B\

    It's much simpler than that. I don't believe you're speaking accurately. And the tone and content of your previous posts reinforce that belief. The claims you are making about software are, to me, equivalent to claims in engineering about inventing a perpetual motion machine.

    \Alex B\
    I was fortunate enough to work in environments where we managed to get our act together, to elevate ourselves beyond the incoherent abusive lurching from post to post. I relate my experiences here in a positive fashion, and all you have to say is 'get out of here'! You are shooting yourself in the foot by refusing to listen to some potentially usefull pointers and tips from the real life trenches. You remind me of those people who plug their ears and walk around shouting 'la-la-la-la!'
    \Alex B\

    You haven't provided any pointers to anyone. All you've done is say that you "nail the end users' goals". No details have been provided in how you managed to do that. You've given no useful information that someone could try and apply to their own projects. Basically, your posts amount to crowing about how brilliant you are, how you've solved all of these petty and trivial problems that the rest of us have so much difficulty with. Frankly, you may not realize it, but your posts are IMHO far more insulting than my own - at least mine have at least a pinch of humor thrown in from time to time.

       -Mike
  25. Somethings getting nailed, thats for sure[ Go to top ]

    Ah, I forgot, you're the guy who also wrote this:

    \Alex B in Dec 2002\
    That exercise forced me to carefuly examine the process of coding, because my framework had to emulate a bunch of real life programmers. Guess what -- I've discovered that the act of programming is a real trivial exercise. Sure, it is way mystyfied, to impress the common folks, but when you get to the bottom of it, it is rather trivial, meaning you can teach a piece of software to do it.
    \Alex B in Dec 2002\

    10 months ago programming was a trivial exercise that you can teach software to do. Now requirements and business needs are trivial, too. I suppose in the next year you'll make testing, performance evaluation, and debugging trivial as well.

    Tell me, Alex, it sounds like you're so smart you've put yourself out of a job!

       -Mike
  26. Somethings getting nailed, thats for sure[ Go to top ]

    <Mike>
    10 months ago programming was a trivial exercise that you can teach software to do. Now requirements and business needs are trivial, too. I suppose in the next year you'll make testing, performance evaluation, and debugging trivial as well.

    Tell me, Alex, it sounds like you're so smart you've put yourself out of a job!
    </Mike>

    The level of intelligence of some of the participants in this forum is starting to worry me. Actually, it's getting to the point of being alarming. Please tell me, dear sir, when did I say that requirements and business needs are trivial? You are making things up as you go, disseminating FUD, with no substantial facts to back your claims.

    It's despicable to read your attempts to put words in other people's mouths, and to pretend as if you know what they'll say next year. Why don't you grow up?

    Alex
  27. Somethings getting nailed, thats for sure[ Go to top ]

    Mr. B, it's called "sarcasm". I'm already quite grown, thank you, but you may wish to grow a sense of humor yourself. And you might - just might - want to consider why so many people here consider your claims outrageous, outrageous to the point of being an object of ridicule. To put it plainly, you're making claims that most developers consider nonsense.

        -Mike
  28. You live in a fantasy world[ Go to top ]

    <Alex>
    Not really. The customers always want to add features to the products that don't meet their expectations. If the products meet their expectations, what's to add?
    </Alex>

    I guess you just haven't seen what I have seen. But let's take a hypothetical, shall we...

    Let's say you design some sort of commerce application for a customer. Knowing you, you knock it out whiz-bang in no time. The second you start writing code you have all the requirements down. The *very* first time your users see it, they say, "Holy crap! That is *exactly* what we wanted. Let's put this into production/start selling it/start using it tomorrow!" This sounds like your average project, no?

    Now, let's say your customer comes to you in six months and says, "Golly, you know that awesome software you built us. Well, the thing is business is great and we have expanded to Asia and South America. We now want our application to work with multiple languages and currencies". How I see it, you have three choices:

    1) You tell them to go to hell. You *never* touch software once it is production!
    2) You *anticipated* this, and your application already works with 700 and languages and 200 currencies. I would call this over-engineering, but whatever.
    3) You add this feature.

    Now, clearly you answer *cannot* be #3 (although, it's the correct answer). You already said this:

    <Alex>
    If you manage to understand and truly nail what is it they are really trying to do, trust me, no "ifs" will raise their ugly head. I've been through that, and I've seen with my own eyes that it works that way.
    </Alex>

    So which one is it, #1 or #2.

    BTW - what kind of software do you develop? In-house? Consultant that develops in-house? Product? Just curious. Seriously, I want to work in your fantasy camp.
    ("Do nothing, fall ass-backwards into money, mooch food off your neighbors, and have sex without dating. That's a fantasy camp.")

    Ryan
  29. You live in a fantasy world[ Go to top ]

    <Ryan>
    Now, let's say your customer comes to you in six months and says, "Golly, you know that awesome software you built us. Well, the thing is business is great and we have expanded to Asia and South America. We now want our application to work with multiple languages and currencies". How I see it, you have three choices:

    1) You tell them to go to hell. You *never* touch software once it is production!
    2) You *anticipated* this, and your application already works with 700 and languages and 200 currencies. I would call this over-engineering, but whatever.
    3) You add this feature.

    Now, clearly you answer *cannot* be #3 (although, it's the correct answer). You already said this:
    </Ryan>

    Answer number 3 may or may not be the correct answer. It depends. However, there is also a number 4 answer (of which you obviously know nothing, since you failed to mention it, and yet you are arrogant enough in your ignorance to ridicule people who know more than you do). In one of my previous posts (which I'm sure you haven't read, seeing how you chose to pigeonhole me as someone who's living in a fantasy world), I've explained what happens in my world when the business model changes. The scenario you've described above is one such case, when something substantially new occurs. Of course, the original system was built to address specific goals, and when the goals change, the system ceases to be valid. I've never said that the systems I build will remain valid until the end of time. Every system has its lifetime (usually three to five years, roughly speaking).

    The bottom line question here is: how frequently do the goals change? How likely are the goals to change?

    If you answer is 'almost every day', than I'd say that you haven't captured the essential goals, and are fussing over superficial symptoms instead. Typically, once you determine the goals of a certain business model, these goals tend to be stable (until the business model changes, that is, and how frequently is that going to happen? The fact that the business model in your example changed to encompass new continents is a major 'tectonic' change, something that doesn't happen every month, as I'm sure you'll agree).

    Of course, it is POSSIBLE that such goals will change. But my focus is not on what's POSSIBLE, it's on what's PROBABLE.

    This is where the fundamental difference between my approach to software development and your approach are. You seem to design and build your solutions by leaving them open to address many future possibilities. That means you build them with a main focus on maintennace. I, on the other hand, build my solutions to only address the needs at hand. As soon as I successfully finish fulfilling immediate needs, I stop. Yes, I too can imagine many possibilities that may strike in the future, but I try never to overbuild. I follow the adage 'we'll cross that bridge when we get there', or 'laziness is a virtue'. Consequently, I don't address the maintenance issues, because when the time comes when the existing system ceases to fulfill the needs, we need to go back to the drawing board anyway, and by that time we'll probably conclude that an altogether new system neds to be built (and I'm speaking from a previous experience).

    But I'm sure you won't be able to grasp this concept, as you seem to enamored by your approach to building the 'one size fits all' solution.

    It really is not very intelligent of you do hastily decide to deride the experiences I've decided to share with you, instead of seeing if there is something you could perhaps learn from them. Shutting down any dialog like that is a surefire sign of dogmatic way of thinking. But, it's your loss in the end.

    Alex
  30. You live in a fantasy world[ Go to top ]

    <Alex>
    This is where the fundamental difference between my approach to software development and your approach are. You seem to design and build your solutions by leaving them open to address many future possibilities. That means you build them with a main focus on maintennace. I, on the other hand, build my solutions to only address the needs at hand. As soon as I successfully finish fulfilling immediate needs, I stop.
    </Alex>

    There, I would disagree. I sounds like our approach is fundamentally the same. Build only what you need. Worry about later later. Hmmmm. You just described two philosophies of XP, do the simples thing that could possibly work and YAGNI. This sort of supports my *original* claim the XP and its kind have injected some positive ideas into software development.

    BTW - I don't build then for maintenance. I build then so that 1) they work 2) the code is clean 3) the code is fast. If you strive to keep you code functioning properly and clean, then you *are* build for maintenance! Geez! On a side note, the apps I work on get upgraded *far* more often then three to five years. But I almost exclusively on in-house web applications (commerce web site, intra/extranets). I can't fathom adding features to a commerce web site only 3-5 years. Again, this is why I think are work in drastically different.

    <Alex>
    But I'm sure you won't be able to grasp this concept, as you seem to enamored by your approach to building the 'one size fits all' solution.
    </Alex>

    When did I say that? One size fits all? Talk about putting words in people's mouth.

    <Alex>
    It really is not very intelligent of you do hastily decide to deride the experiences I've decided to share with you, instead of seeing if there is something you could perhaps learn from them. Shutting down any dialog like that is a surefire sign of dogmatic way of thinking. But, it's your loss in the end.
    </Alex>

    What the hell can I learn? Are you teaching? All you said "I nail requirements every time." So? What if I said "I drive the ball 280 yards down the middle of fairway every time." Hurray for me. Can you learn from that?

    All I know is in my experience, requirements are a moving target for *many* reasons. Sometimes users don't know what they want until they see what they don't want. That's why you nail the "core" requirements, show them your first couple of iterations of the application, and then they see what they are getting. Then you can fine tune. Fine tuning detailed, non-core requirements seems silly to me in the opening phase of project. From my experiencem, you just can't. And if you tell me I am wrong (like you have earlier) because *your* experience is different, then you are just guilty of the same stuff you are accusing me of.

    Ryan
  31. You live in a fantasy world[ Go to top ]

    <Alex>
    But I'm sure you won't be able to grasp this concept, as you seem to enamored by your approach to building the 'one size fits all' solution.
    </Alex>

    <Ryan>
    When did I say that? One size fits all? Talk about putting words in people's mouth.
    </Ryan>

    I never said that you did say how you're building the one size fits all solutions. All I said was that you *seem to be enamored* by that approach (please go back and read what I wrote). I wasn't putting words in your mouth, I was simply relying my impression of you, which may or may not be correct (since I don't really know you).

    I'd like to throw in a quote I've stumbled upon in a separate thread, in the hopes that it may force some people to reconsider (and Ryan, this quote is not thrown at you, so please don't take offence):

    "That's the problem with stupidity, it lets you think you're clever, when you're not, when you can't even parse a simple document without inventing stuff."
  32. We're not worthy![ Go to top ]

    Alex,

    You must be a genius! You are the only person I know of who has completed the amazing double act of capturing a customer's requirements 100% accurately first time around, and written completely bug-free software which has required no maintenance coding since its first release. Congratulations!

    Was your customer's goal to print "hello world" on the screen?

    Personally, I think far more people are using XP now than ever before (or at least most of the suggested XP practices - pair programming has been a hard sell to most companies), there is just less hype about it these days because most people already know about it...
  33. We're not worthy![ Go to top ]

    <Lawrie>
    Alex,

    You must be a genius! You are the only person I know of who has completed the amazing double act of capturing a customer's requirements 100% accurately first time around, and written completely bug-free software which has required no maintenance coding since its first release. Congratulations!
    </Lawrie>

    Again, some less intelligent participants are putting the words in my mouth. When did I say that I've written a completely bug-free software? Please get your acts straight before you attempt to slander other people.

    Alex
  34. No maintenance != no bug-fixing ???[ Go to top ]

    <Alex B>
    Again, some less intelligent participants are putting the words in my mouth. When did I say that I've written a completely bug-free software? Please get your acts straight before you attempt to slander other people.
    <Alex B>

    Less intelligent? At least I can remember what I post a couple of hours earlier ;)

    To refresh your memory, it was in your earlier post (#98010) where you stated that the system you'd written required no maintenance. And no maintenance means no bug-fixing. Therefore you implied that this software was completely bug-free...

    <Alex B>
    One product I've built in 1996 is still in production, in pristine condition, untouched in the last 7 years, working like a charm around the clock. NO MAINTENANCE, no enhancements, no nothing
    <Alex B>
  35. Last nail in Struts[ Go to top ]

    I'd recommend for everyone who is disappointed by Struts to look at Tapestry.
    In early days of Java web applications I had experience with servlets and JSPs (bare and taglibs). I looked at Struts and concluded that it is, in short, overdesigned. But Tapestry was really amazing discovery. In my view it's what web application framework is supposed to be. No shit, just real stuff.

    http://jakarta.apache.org/tapestry
  36. In defense of the Struts-heads[ Go to top ]

    <QUOTE>
    the Struts-heads incessantly trumpet how important it is to separate business logic from the presentation etc., but my question is -- why is it so important?
    </QUOTE>

    I don't think that it is just the "strut-heads", as you call them, which think it is important to separate business logic from the presentation. In fact I have never heard a single person until now suggesting that it is not important. The issue has never been if you should try to separate the presentation from business logic, but what is the best way to do it. Most of the other web frameworks try to do this in one way or another

    <QUOTE>
    I just don't understand what is it that Struts offers that cannot be done in Velocity?
    </QUOTE>

    Struts is a web framework that focuses on the control of the web application. Velocity is not a web framework, it is a template engine. You can use velocity instead of JSP within Struts for rendering your content if you like, and in fact this is often a nice solution. Struts and velocity are trying to solve completely different problems.

    The main functionality in struts is:
    they seem to wallow in unnecessary complexity, in maintaining those countless, pointless XML configuration files
    </Quote>

    There is a lot of stuff in struts, but most of the complex parts are optional, you don’t have to use them if you don’t think that they will provide value to your project. Although, for larger web applications I think that you would end up having to re-invent a lot of these services. The basic components of Struts are:

    <Quote>
    A controller servlet that dispatches requests to appropriate Action classes provided by the application developer.

    JSP custom tag libraries, and associated support in the controller servlet, that assists developers in creating interactive form-based applications.

    Utility classes to support XML parsing, automatic population of JavaBeans properties based on the Java reflection APIs, and internationalization of prompts and messages.
    </Quote>

    You don’t really need to use the JSP tags or the Utilities, but I think that they actually speed up development. Struts is not perfect, and there are some annoyances, mainly with configuration, but there are many tools, both commercial as well as open source, that make it easier to use struts: they have wizards that will generate a lot of the Struts infrastructure components so that you can focus on the business logic. I find that using such a tool actually makes it faster to develop with struts than just plain old JSP

    As for the “countless, pointless XML configuration files”, there is only one xml configuration file that is required by Struts (struts-config.xml), although, if you have a large project you can use multiple configuration files to break the project up into more manageable units. The other file that you may be thinking of, web.xml, is part of J2EE and would be needed even if you are not using Struts. It seems to me that you are not very familiar with Struts; luckily, as the article points out, there are tons of resources available for learning Struts.

    There seems to be a lot of anger at Struts because it has become the most popular web framework. I think that no technology should be adopted without considering if it is appropriate for the given project, but the article discusses this issue in a completely one sided way. The article neglects to mention the dangers in under-engineering an application. I have seen a number of sites that were developed with just JSP’s, without any framework, because they thought a framework was overkill. Many of these applications quickly grew beyond their humble roots, and they became maintenance nightmares. The structure imposed by using Struts, or some other MVC framework, often leads to a site that is much easier to extend and maintain. Furthermore, IMHO, once you get used to working with it, the development overhead is not nearly as significant as these folks would have you believe.

    There a large number of alternative web application frameworks that you can choose from, if you really hate Struts. However, there is something to be said for using the one that most other people are using. Before Struts, I developed a proprietary web framework that was used on several projects. It was lighter weight and used reflection and a naming convention to determine the action to instantiate (rather than using the xml configuration file), but it provided some of the same basic MVC services that Struts provides. Once Struts caught on we decided to switch to Struts. One of the advantages of that decision is that many of the new developers joining our project already knew Struts. We didn’t need to bring them up to speed on our proprietary framework. Another benefit was the form bean validation in Struts. My framework didn’t provide the validation service that Struts provides. Looking back at the applications that were developed with my framework, one of the bad points was that the validation code was mixed in with the rest of the action code, and made it more difficult to see exactly what the action was doing (Hindsight is 20/20).

    I believe that the “struts-heads” are aware that their solution is not always the appropriate one. The following is a quote from the Struts web site:
    <QUOTE>
    Is Struts the best choice for every project?
    No. If you need to write a very simple application, with a handful of pages, then you might consider a "Model 1" solution that uses only server pages
    </QUOTE>
  37. I don't think that it is just the "strut-heads", as you call them, which think

    >it is important to separate business logic from the presentation. In fact I
    >have never heard a single person until now suggesting that it is not important.
    >The issue has never been if you should try to separate the presentation from
    >business logic, but what is the best way to do it. Most of the other web
    >frameworks try to do this in one way or another

    You are right, it is not only "struts heads" who talk about separating business logic form presentation. It's the entire cult, a huge following that somehow emerged and is now absolutely careening out of control.

    What's truly worrysome is that no one ever stops to examine the fundamental assumption underlying this entire madness. You have commented how I'm the only person you've ever heard of who had voiced such concerns. That's enough to illustrate how much out of controll this whole thing is.

    Taking anything uncritically and running with it, defending it at any cost, is a surefire way that one has turned into a crusty old dogmatic. So now we have this 'business logic separation' dogma ruling our roster. Fine, but ask yourself this: why do we trust it so blindly? What's the real benefit of sticking to this dogma?

    The problem is, no one is asking those questions. Just because you read an article on javaworld.com exuding the virtues of Model 2 architecture, doesn't automatically meant that everything in there should be taken in as a gospel. Come on, people, you have your own brains, use them once in a while! Don't just eat up everything the media serves you.

    To my understanding, the only defensible reason why we would need to go through so much pain in order to separate business logic form the presentation is to make the subsequent maintenance easier and less epxensive. But, as I've argued elsewhere in this thread, the much dreaded maintenance is just another myth. Field evidence has demonstrated that if the software product is built in such a way to meet the needs of the users, no subsequent maintenance will ever be necessary.

    If that's the case, what is to be gained from separating business logic from the presentation? I can't see any valid reason for going through so much pain in order to gain practically nothing.

    Can anyone come up with more convincing reasons?

    Alex
  38. <!-- Don't just eat up everything the media serves -->

    Alex, I think you are right. But unfortunately most of the people in developer community seem to be still in infancy. They can fight hours on vi/emacs, or C#/Java/C++, but they never seems to realize how monopoly of big companies is killing and hurting them as a developer and small companies.

    Just take an example, how the Web Services "FAD" preempt some reasonably good middleware companies like "orbix" and "inprise", and get the balance in favor of big giants:-) my 2 cents.

    We all learn the lessons with time, may be we do to, but sooner the better.
  39. "What's the real benefit of sticking to this dogma? "

    Good question. I don't believe in doing something "just because" either.
    But, 'll give you a real-life scenarion where the separation is important.

    My current employer writes web applications that provide services to the populations of other employers. Much of the business logic is the same across those different clients. But, they all want their own branding and look and feel. If the business logic was embedded in the display we'd have to duplicate the logic or have umpteen if(client == foo) else if (client == bar) blocks all over the place. I think you get the picture.

    We don't use struts but we do keep separate as much as possible the businesss logic from the view.
  40. My current employer writes web applications that provide services to the

    >populations of other employers. Much of the business logic is the same across
    >those different clients. But, they all want their own branding and look and
    >feel. If the business logic was embedded in the display we'd have to duplicate
    >the logic or have umpteen if(client == foo) else if (client == bar) blocks all
    >over the place. I think you get the picture.

    So let me ask you this: supposing that nothing changes once you deliver the application, what's more painfull -- duplicate the logic or set up a more or less flakey Mickey Mouse framework that will attempt to separate the business logic from the presentation? And to be realistic for a moment here, I hope you all recognize that most of the popular frameworks on the market today do a pretty lousy job at separating the two clearly. Regardles of which framework one chooses, and regardless of how one sets things up, some of the business logic always and inevitably bleeds through into the presentation layer (and vice versa). So anyway the whole thing is a joke. But even if it were possible to achieve a razor sharp and completely opaque separation, the question still remains: what for?

    This whole layered architecture is a funny business anyway. It's very hard to justify its business case. I've been working at it for many years, building monumental and spectacular frameworks (because it's a grand challenge that really tickles my fancy, and presents an excellent diversion at work -- makes the hours go by faster, and gives me a sense of accomplishment at the end of the day), but somehow I always had huge problems selling the layered architecture ideas to anyone who's at least a bit savvy. People demand results from me, they don't endorse my attempts to create a fun environment for me and my developers.

    By the way, and as a side note, couldn't you use cascading stylesheets for delivering the branding and look and feel solution?

    Alex
  41. clarification[ Go to top ]

    You are right, it is not only "struts heads" who talk about separating business logic form >presentation. It's the entire cult, a huge following that somehow emerged and is now >absolutely careening out of control.

    >
    >What's truly worrysome is that no one ever stops to examine the fundamental >assumption underlying this entire madness. You have commented how I'm the only >person you've ever heard of who had voiced such concerns. That's enough to illustrate >how much out of controll this whole thing is.

    Let me clarify, what I meant was that I had never heard anyone touting a template based UI solution such as JSP or Velocity and also not think that it is important to keep the business logic out of the UI template. I don't want to go into the whole history of the debate between people who like the template based approach and people who like code to generate the HTML (an option that I think would be far better than going half and half where there is a bunch of business logic inside your UI templates. I have seen the disastrous results of people doing this and I am very glad that in your world systems don't need to be maintained or to be evolved after being deployed, because based on this approach it would suck to be the poor bastard who got stuck trying to do that.

    Anyway, I think I now understand why we disagree on just about everything. It turns out that we are living in different universes. The nature of software development in my universe seems to be different than it is in your universe.

    Best of luck to you and your clients.

    PS: Just out of curiosity, you didn't by chance participate in any of the Forester studies of development did you?
  42. You've nailed it![ Go to top ]

    PS: Just out of curiosity, you didn't by chance participate in any of the Forester studies of development did you?


    Hahaha, that's a good one! Actually, I'm the one pulling all the strings behind the scenes, if you must know.

    Alex
  43. Separation of Business/Presentation Logic[ Go to top ]

    The separation of business and presentation logic isn't done strictly to make maintenance easier (although I believe it does to some extent).

    It is more a matter of decoupling the two tiers so that you can reuse components from either tier. Most often this occurs when a business component is used in (a) a completely different UI tier (console based, Swing, HTML page, web service, etc.) (b) a different presentation layer (XSLT, JSP, Velocity Template, WML etc.) or (c) a new use within the same front end (such as taking two steps from a 6 step wizard and incorporating them into a related wizard for a separate business group).

    If you don't separate the presentation and business logic, this type of reuse occurs via cut and paste. And at that point, you have a maintenance headache when logic needs to change.

    Not everyone believes in maintaining this separation, there are plenty of AS/400 developers out there that will agree with you completely. But most people who have worked with systems of moderate complexity that are not just small applications out there living in their stovepipe will probably agree that logical partitioning is one of the simplest ways to decrease costs for system development.
  44. Separation of Business/Presentation Logic[ Go to top ]

    <John E>
    The separation of business and presentation logic isn't done strictly to make maintenance easier (although I believe it does to some extent).

    It is more a matter of decoupling the two tiers so that you can reuse components from either tier.
    </John E>

    Thank you for providing a very articulate case for separating business logic from the presentation (other than for maintenance reasons, which we all agreed is the valid reason). Although I think I understand your reasoning, I must confess that I'm still very much mystified by it. Allow me to explain:

    The reason we've switched to object oriented development some 10 years ago is because we wanted, among other things, to capitalize on the reuse. At that time, OO technology seemed to be the best bet for achieving this reuse. And I think it still is today, unless I'm overlooking something (corrections are more than welcome).

    Then, out of nowhere, theories started emerging telling us how we're not reusing our code. Theories that claim that unless we go through excrutiating pains of separating business logic from the presentation, we're doomed to the 'cut and paste' hell.

    But, wait a minute -- isn't the fact that we design our application logic by implementing it using objects as abstractions enough of a guarantee that we won't have to cut and paste? Why do we need this extra nuisance of jumping through the hoops, using those half-baked 'frameworks', half-assedly separating business logic from the presentation? That's what I'm not clear on.

    In your example, you talk about a business component that may be used in different contexts. Fine. I already have that component (because I always design and implement all my business abstractions as components), only I choose to call it 'object'; same difference, right? Can't I simply use that component anywhere, without having to worry about the extra step of using it through some Mickey Mouse extraneous framework? My components are always carefully designed to be self-sufficiant, standalone, independent of any other abstractions. Why can't I simply mention that component in my code? What's wrong with that? Why the charade with so much indirection? Seems to me, by looking at the Struts related code, that these people are just wasting so much time beating around the bush. Yeah, I understand, sometime in the future the post may elicit a different page in response (the 'action' changes), but how likely is that to happen anyway? Let's be realistic for a moment. Usually, the responses to the requests are clearly nailed early on in the analysis, and tend to be one of the most stable parts of the application. Introducing such huge overhead just so that an eventual chage in the workflow (which may or may not happen; your guess is as good as mine) could be handled declaratively is simply not worth all the extra effort. What's wrong with going into the code and changing one line which determines the action? Isn't that much, much simpler and cheaper?

    As you can see, I'm very big on pragmatics, and very skeptical when it comes to embracing theoretical constructs. Yes, these constructs may be innovative, elegant, even brilliant, but what exactly are they buying me? Usually, I find that they don't buy me anything but grief.

    Alex
  45. Separation of Business/Presentation Logic[ Go to top ]

    \Alex B\
    The reason we've switched to object oriented development some 10 years ago is because we wanted, among other things, to capitalize on the reuse. At that time, OO technology seemed to be the best bet for achieving this reuse. And I think it still is today, unless I'm overlooking something (corrections are more than welcome).

    Then, out of nowhere, theories started emerging telling us how we're not reusing our code. Theories that claim that unless we go through excrutiating pains of separating business logic from the presentation, we're doomed to the 'cut and paste' hell.

    But, wait a minute -- isn't the fact that we design our application logic by implementing it using objects as abstractions enough of a guarantee that we won't have to cut and paste? Why do we need this extra nuisance of jumping through the hoops, using those half-baked 'frameworks', half-assedly separating business logic from the presentation? That's what I'm not clear on.
    \Alex B\

    If I'm understanding you correctly, you appear to be saying that you're using objects, so you must have re-use. Is this correct?

    In general terms, switching from a procedural language to an OO one doesn't guarantee anything - the nature of your problems may change, but you'll still have problems. It's in how you use OO that determines whether your code will be re-usable or not. Frameworks (hopefully not half-baked, but instead correctly sized) are one way of getting there - and the good ones are expressly dsigned to help users achieve re-use of their own code. Simply using "objects", though, doesn't mean much of anything. You can mis-use objects just as anything else can be misused. Perhaps you think seperating biz logic out from presentation is a bad idea - OK, you're entitled to your opinion. But your opinion flies in the face of the experience of a majority of developers out there. For most of us, seperating presentation from business logic has been a clear win. Things do change, far more often then you indicate, and often we are asked to present the same business component in different visual views - in both of these areas you want to seperate presentation from biz logic so that you state your biz logic once and only once.

    As for your closing rant against struts - it's in my opinion absurd. One of your rants says:

        "Usually, the responses to the requests are clearly nailed early on in the analysis, and tend to be one of the most stable parts of the application".

    So you're saying that page flow, including responses, is one of the most stable parts of an application.

    In my experience, page flow is one of the _most_ volatile parts of an application, and the area _most_ likely to change. I believe a majority of people here agree with that. So your experiences, if true, disagree violently with the experience of many other people here.

        -Mike
  46. Separation of Business/Presentation Logic[ Go to top ]

    \Alex B\
    As you can see, I'm very big on pragmatics, and very skeptical when it comes to embracing theoretical constructs. Yes, these constructs may be innovative, elegant, even brilliant, but what exactly are they buying me? Usually, I find that they don't buy me anything but grief.
    \Alex B\

    Earth to Alex: Struts is not "a theoretical construct". Seperation of presentation from biz logic is not "a theoretical construct". Struts is real, thousands of people use it every day. Seperation of business logic from presentation logic is a common practice on thousands of very real applications. These are very, very pragmatic approaches to a common problem.

    On the other hand, _you've_ offered nothing but theoretical arguments and assertions that can't be verified. So frankly I believe your argument is exactly bass ackwards.

        -Mike
  47. Separation of Business/Presentation Logic[ Go to top ]

    The object you describe sounds like it contains your business logic, and your presentation logic is probably in a servlet or a JSP. While this is not Model 2, I think it is still clearly a separation of business and presentation logic. You don't pepper HTML in that object, nor do you have database connections or business workflow in your JSP (I'm just guessing here admittedly). I read a previous post of yours to mean that you don't advocate any separation of business from presentation logic, but it sounds like you advocate this separation to some extent. (The separation, not MVC or Struts or other web frameworks)

    IMHO, the primary benefit I've seen from MVC is the separation of formatting logic from navigational logic. So the presentation tier is really separated into two more tiers, the view and the controller. In some applications (in my case MANY of the applications I've been fortunate enough to work on), there are benefits to centralizing things like exception handling, internationalization, input validation, and page navigational flow from the resulting view that is presented to the users. This is where MVC has really proven itself for me. Granted, it can bring its own group of headaches, but nobody is claiming that MVC or Struts is a silver bullet to end all problems inherent in web application development. Rather, frameworks like Struts or Tapestry offer solid ways to leverage code that has already been written by people who understand the paradigm much better than I do instead of trying to write it myself. This doesn't mean that I would never work on a project that didn't use one of these frameworks or even MVC at all.

    I think the thing to keep in mind here is that the primary reason the article pointed out Struts and XP and railed against them is that because of their popularity and momentum, the article is sure to generate lots of interest. But I haven't met many people in the real world who say XP or Struts are the one true way. (even though the author painted advocates of these two that way). I think most people take the approach of using what they like from XP and combining it with what they like from other methodologies. Ditto for Struts (I've never used the Datasource functionality from Struts and I've never had to plug in my own RequestProcessor) AFAIK, the author takes a straw man approach in his arguments regarding Struts and XP.
  48. Separation of Business/Presentation Logic[ Go to top ]

    <John E>
    The object you describe sounds like it contains your business logic, and your presentation logic is probably in a servlet or a JSP. While this is not Model 2, I think it is still clearly a separation of business and presentation logic. You don't pepper HTML in that object, nor do you have database connections or business workflow in your JSP (I'm just guessing here admittedly). I read a previous post of yours to mean that you don't advocate any separation of business from presentation logic, but it sounds like you advocate this separation to some extent. (The separation, not MVC or Struts or other web frameworks)
    </John E>

    You're correct. Any time we decide to use OO technology, we agree that we'll be building abstractions that encapsulate certain portion of the capability of the system. And, quite correctly, you can say that by doing that we're advocating separation. And I'd like to add -- not to some extent, but to the fullest extent possible.

    You're also correct in stating that we're not convinced that so called 'web frameworks' (i.e. Struts, MVC etc.) are alleviating our development pains more than they are incurring additional, previously non-existent pains.

    The benefits of centralizing exception handling, i18n, validation, navigational flow etc. are perfectly achievable using the standard OO analysis and design techniques. The only thing that web frameworks seem to be proposing in addition to the stuff available through vanilla OO analysis and design, is an infinitezimal portion of declarative programming. We acquire a modicum of the ability to declare our intentions, instead of defining them procedurally, but at what cost? Not worth the trouble, in my opinion.

    I am also a big proponent of the 'separation of concerns' principle, which I insist we apply in the construction phase. However, we don't need a third party framework in order to put that principle into practice.

    The biggest problem with Struts and other such frameworks is that they are too generalistic. They attempt to be all things to all people (or, as I'm fond of putting it, one size fits all). There's a huge overhead associated with that. True, one doesn't need to use or mind the extraneous stuff that's thrown in if one doesn't want to, but that extra stuff creates just too much noise for us to be comfortable with (both in the learning ramp up phase, and in the subsequent production phase). I'd rather always go with a lean, keen codebase that's focused on solving my problem at hand, and nothing else.

    Alex
  49. Separation of Business/Presentation Logic[ Go to top ]

    \Alex B\
    The biggest problem with Struts and other such frameworks is that they are too generalistic. They attempt to be all things to all people (or, as I'm fond of putting it, one size fits all). There's a huge overhead associated with that. True, one doesn't need to use or mind the extraneous stuff that's thrown in if one doesn't want to, but that extra stuff creates just too much noise for us to be comfortable with (both in the learning ramp up phase, and in the subsequent production phase). \Alex B\

    Struts is too generalistic? "Huge overhead"? "Too much noise"?

    Doesn't sound like you're talking about the same Struts that I've used. You must mean two other Struts down the road.

    \Alex B\
    I'd rather always go with a lean, keen codebase that's focused on solving my problem at hand, and nothing else.
    \Alex B\

    From your descriptions, you solve the same problem - over, and over, and over, and over, and over...and over again. A framework like Struts exists to abstract out and solve one specific problem so you don't end up writing the same boilerplate code over and over again.

        -Mike
  50. Curious - any frameworks you _do_ like?[ Go to top ]

    A thought struck me while I hit "reply" a moment ago. Are there _any_ frameworks, in any domain, that you approve of? Reading through your old posts you seem to bash everything, and praise nothing. J2EE is too complex, Struts is too complex. Do you like _anything_ outside of the base language?

    Or do you keep your job by repeatedly reinventing the wheel, and keeping your group as far away from those _nasty, nasty_ frameworks which have shortened pretty much everyone else's development times on the planet?

        -Mike
  51. Curious - any frameworks you _do_ like?[ Go to top ]

    <Mike Spille>
    Are there _any_ frameworks, in any domain, that you approve of? Reading through your old posts you seem to bash everything, and praise nothing. J2EE is too complex, Struts is too complex. Do you like _anything_ outside of the base language?
    </Mike Spille>

    Yes, I like plenty of things. I like all the things that deliver quality to me. By quality I mean make my job easier and more enjoyable, while hiding from me the ugly "how" is it actually doing it. It's similar to a car -- I like my car, because it is usefull for me and it's fun to use to boot, and at the same time I don't have to know absolutely anything about how my car is actually working. All I have to know in order to use it (besides knowing how to drive, of course), it how to put the key into the ignition, how to turn the key to start the engine, how to put the car into drive (or reverse, as the case may be), how to disengage the park brake, how to step on the gas pedal, or the brake pedal, and how to steer the steering wheel. That's pretty much it! Knowing these simple things allows me to control this incredibly complex, incredibly powerfull machinery.

    I like software products that resemble my car. Give me just a handfull of simple steps that I need to memorize, and let me do the driving.

    I wouldn't want to use this forum for advertising any products, but if you must know, Castor is one such product that I immenselly enjoy using (and I've been using it for a long time now). Another one would be Resin (which absolutely drives circles around Tomcat). There's milions of these great products that no one ever talks about. Ever wonder why? Because they are not problematic, they are not contradictory and confusing, they really and truly address their customers' goals, and as such don't have to be analyzed and turned inside out. Customers are just delighted to use them.

    Sadly, in a way, achieving success in software victimizes you, as you don't generate enough hype and thus fall into obscurity. Lousy products, on the other hand, generate so much stir and publicity that people can't stop talking about them, and thus they rise to prominence (did anyone mention Microsoft Windows?)

    Alex
  52. Curious - any frameworks you _do_ like?[ Go to top ]

    Hey, we're making progress now.

    So - how is Resin and Castor compatible with OO, but somehow Struts is not? Why do you complain that using Struts is fluff, but using Castor is not fluff?

    And how does Castor, for example, resemble a car? Castor is just as complex as Struts (if not more so). You don't drop Castor into something in 5 minutes and awawy you go - there's alot you need to know to use it, and it's certainly nothing like a car in its simplicity.

    You may not realize it, but Castor has as many problems and as many haters as Struts has.

    What I'm getting at is this: you seem to be applying one level of criteria - an impossibly high level - to something like Struts. Then you say that something like Castor is agreeable to you, even though it fails down by criteria _you've_ put forth here.

    What is it that really bugs you about Struts? How could it be fixed so that it doesn't bug you? No hand waving and generalities - specifics, please. Cite some actual code examples if you can.

    What is it about Castor that you like - and _please_ don't say that it's like a car!!!! What aspects of Castor (specifically!) should other 3rd party packages aspire to?

        -Mike
  53. Curious - any frameworks you _do_ like?[ Go to top ]

    <Mike Spille>
    What is it about Castor that you like - and _please_ don't say that it's like a car!!!! What aspects of Castor (specifically!) should other 3rd party packages aspire to?
    </Mike Spille>

    Mike,

    I'd hate to hijack this forum and turn it into some sort of an educational session. So, I'll try to be brief. There is millions of things that could be said on this topic, and one could write volumes explaining these things, but this is not the forum for that. Just so that you know, I do teach principles of software development part-time at several local universities, so I have plenty of experience in that arena, and I know from the first hand evidence how boneheaded people tend to be when you question their set ways of doing things. Anyway, on to the explanation:

    You are right, of course, in saying that Castor is an incredibly complex product. And I'm not saying that it's even solidly built. I'd be the first one to openly admit that it is actually quite Mickey Mouse-ish. I've invested a lot of time in studying the source code that comes with Castor, and went away scratching and shaking my head in disbelief at the overall lousiness and unevenness of the product's internals.

    And yet, I can't help but loving it! You may be right, after all, perhaps I do live in a different universe. In any event, you can see that technical excellence is of secondary importance to me (in other words, i'm not a geek or a nerd).

    Why do I love Castor so much? Simply put, it makes my job million times easier than it would've been without Castor. At this point, I'm actually scared to admit, but I simply couldn't live without Castor, warts and all.

    To cut the long story short, Castor is my saving grace from the XML hell. I love XML Schema, but I intensely dislike working with XML. Castor allows me to declare all my abstractions in an XML Schema document, and then type this:

    java org.exolab.castor.builder.SourceGenerator -i myschema.xmlschema

    The above single line command generates all the objects with all the validating code for me. Then, instead of working directly with the low-level data storage technology (i.e. XML), I simply talk to my objects, and let them worry about their own persistence (i.e. marshaling and unmarshaling).

    So basically, for my needs, all I need to know in order to use these fantastic services is how to create XML Schema documents, and how to run Castor's SourceGenerator facility. Everything else happens as if by magic. I thankfully stay in the OO world, where I'm most comfortable, and yet I participate in the ugly smelly world of XML, which is where most of my suppliers, customers and service providers live. And all that for free? I think I died and went to heaven.

    I think it is very clear from this example that Castor is a life saver for me. In that respect, it *is* like a car (I know you hate this analogy, but I can't help it). I just declare my abstractions, push the button, and voila! -- I have all the objects simply appear before me.

    What could other 3rd party packages learn form the success story of Castor and other similarly great products? One thing only -- focus on your customers' goals. Castor rightly identified that the goals of its customer base is to leave the pesky world of SAX and DOM parsing, to forget all about stupid and unwieldy XML tags, and to simply continue working in the familiar world of objects. Castor delivered exactly that with minimal amount of fuss. All it expects me to know is XML Schema (a world wide standard, and a good one at that), and how to 'start the engine', that is, invoke its SourceGenerator (a one line command which could be encapsulated inside a simple script file). Nothing related to Castor is taxing, everything points to freedom. It is indeed a very desirable product, and at this point I wouldn't trade it for anything else.

    Compare this simplicity and power to the kludge that Struts is -- very taxing on my short term memory, very convoluted, sending me mixed messages. It even forces me to look at its butt-ugly XML configuration files? Thanks, but no thanks! Not clear which pressing goal of mine is Struts addressing? Indirection? I don't care too much about that. Declarative programming? Six one way, half dozen the other. Where's the benefit? Struts is a very tough sell, unless you're unconditionally enamored with technology per se, and just cannot live without fiddling day-in/day-out and masochistically torturing yourself untill your eyes bleed.

    Alex
  54. Has this all been a joke?[ Go to top ]

    First you give us something like this
    <QUOTE>
    Yes, I like plenty of things. I like all the things that deliver quality to me. By quality I mean make my job easier and more enjoyable, while hiding from me the ugly "how" is it actually doing it. It's similar to a car -- I like my car, because it is usefull for me and it's fun to use to boot, and at the same time I don't have to know absolutely anything about how my car is actually working. All I have to know in order to use it (besides knowing how to drive, of course), it how to put the key into the ignition, how to turn the key to start the engine, how to put the car into drive (or reverse, as the case may be), how to disengage the park brake, how to step on the gas pedal, or the brake pedal, and how to steer the steering wheel. That's pretty much it! Knowing these simple things allows me to control this incredibly complex, incredibly powerfull machinery.

    I like software products that resemble my car. Give me just a handfull of simple steps that I need to memorize, and let me do the driving.

    I wouldn't want to use this forum for advertising any products, but if you must know, Castor is one such product that I immenselly enjoy using (and I've been using it for a long time now). Another one would be Resin (which absolutely drives circles around Tomcat). There's milions of these great products that no one ever talks about. Ever wonder why? Because they are not problematic, they are not contradictory and confusing, they really and truly address their customers' goals, and as such don't have to be analyzed and turned inside out. Customers are just delighted to use them.
    </QUOTE>

    Then you give us something like this

    <QUOTE>
    You are right, of course, in saying that Castor is an incredibly complex product. And I'm not saying that it's even solidly built. I'd be the first one to openly admit that it is actually quite Mickey Mouse-ish. I've invested a lot of time in studying the source code that comes with Castor, and went away scratching and shaking my head in disbelief at the overall lousiness and unevenness of the product's internals.

    Are you suffering from split personality disorder, are you on any psycho-active substances. Every post seems to contradict the previous one.

    Are you really serious about what you have been saying or have you been pulling all our legs. If so, you really had me going. I would be delighted to find out your whole thread was a practical joke. If it was it was brilliant..

    JJ
  55. What is this noise you are hearing?[ Go to top ]

    Struts provides the types of services that most medium to large web applications need (at least in my universe, as we have already established that we live in different universes I can understand why these features are not as useful to you). But when you call it too theoretical, or too generic I don't understand where you get that from, it is not at all theoretical, it is a real implementation. It is not generic either, it provides very specific features that solve very specific problems (At least in this universe, there are many projects that have found it to be a practical solution). And, like I said before, there are many services provided by struts, and if you don't need some of them then you don't have to use them.

    Can you describe the nature of this noise in a more specific way. If you don't use some part of struts you don't need to concern yourself with that part of it. How is that creating noise. You like to make these grand, sweeping, dramatic statements but you don't provide a single concrete example that we can make heads or tails of.
  56. What is this noise you are hearing?[ Go to top ]

    <joe jenkins>
    But when you call it too theoretical, or too generic I don't understand where you get that from, it is not at all theoretical, it is a real implementation.
    </joe jenkins>

    Just because something is a real implementation, doesn't mean that it's not theoretical. For example, a product such as Oracle is a real implementation of the relational theory. Relational theory is based on the mathematical set theory (I hoped you knew that, but then again, what do I know, I live in a different universe, and a very hostile one at that, right?)

    Similarly, Struts is a real implementation of some theory, a theory that at this point looks very muddled to me. It definitelly is someone's theory, but it is not very well articulated. To make things worse, even if it was clearly articulated, it still would be nothing more than a solution in search of a problem. Don't know about you, but I definitelly don't have time for such things. Anyone can come up with a fancy solution and then start looking for a real life problem to solve. But such academic exercise amounts to doing things backwards.

    Just so that you know for future reference, everything in software is based on some theory.

    When I complain that Struts is generic, I'm talking about it being a general purpose framework, which attempts to be all things to all people. Nothing wrong with that, of course, as the example of a general purpose product such as Oracle database illustrates. But, Oracle is a product built on a solid foundation of mathematically proven hypothesis, while Struts strikes me as a hodge podge of a feeble attempt at declarative programming bundled with some utilities and some of the hottest new trends (read hype).

    <joe jenkins>
    Can you describe the nature of this noise in a more specific way. If you don't use some part of struts you don't need to concern yourself with that part of it. How is that creating noise. You like to make these grand, sweeping, dramatic statements but you don't provide a single concrete example that we can make heads or tails of.
    </joe jenkins>

    I've already described the nature of the noise emanating from Struts. You, of course, chose to conveniently parse my explanation out. Now you want me to chew it up for you again so that you could just swallow, without investing any effort. I hate repeating myself, so if you really must know, go back and re-read (I'll give you a hint: unnecessary indirection)

    Alex
  57. Shallow[ Go to top ]

    The article is a collection of assertions with no evidence to back them up. It's the kind of essay they teach you to tear to shreds in a freshman English class.
  58. Soap Box: Software Fashion[ Go to top ]

    I'm too sexy for this thread, too sexy for this thread...

    If you break Struts or XP down to component parts they both offer useful features. The full suit is hard to use. Mix and match.
  59. XP is for juniors[ Go to top ]

    I think most decent developers would be annoyed to have a babysitter next to them while they code. If you have to use Pair Programming, your team stinks. Think about it ... paying two developers to do the work of one? Just hire one good one.

    -geoff
  60. Pear programming[ Go to top ]

    Yeah.. but what if those two guys get their bit up and running (=bug-free) in half the time it would take one "real good" programmer? Just a thought..

    Besides, i like pears :)

    //ras
  61. Was there a case study?[ Go to top ]

    I didn't see any case study; I just saw a lot of unsubstantiated ranting. I didn't see a single alternative technology that they proposed to be used in place of any of the technologies that they were assailing. It is very easy to attack when you have nothing to defend.

    Having said that, there is of course some truth to the article; technologies are often used inappropriately. Extremists get into the habit of solving a problem in on way and they keep solving all problems in that way no matter what. It is easy to find true believers with extreme and flamboyant opinions in the XP/Agile community, or the RUP community, or the ICONIX community, or any other "methodology cult" for that matter. These inflexible individuals can not conceive that any practice outside their own development dogma could possibly provide value. However, the truth is that there is value in many of the practices from each of these "cults", the trick is to find which practices will provide the most value for your current circumstances. There are no easy answers, and no silver bullets, but bashing the current "fashion" in such a superficial way doesn’t really provide much value either, even if it is fun to do.
  62. The success of Linux and Apache Web Server have created the mistaken belief that Open Source is somehow superior to anything else. What is more interesting is that developers buy into this fashion so blindly that they mindlessly contribute to open source project's essentially proped up by companies that are getting their development done for nothing. JBoss LLC and Eclipse are good examples. At the same time software developers complain about job opportunities being lost.

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

    Struts is a good example of essentially a poorly designed framework that because it is open source it must be good. Its poor design does however, appeal to Object Oriented Programmers who only understand one Object Oriented Principle - subclassing. It is MVC only by its own propaganda. An action takes a request, response, action mapping and an action form. How is this model view controller. The API is a superset of that of a standard servlet. If you apply the same Struts best practices you can do the same job easier with a servlet and a lighter weight better designed framework which delegates the handling to a java bean which talks to business interface. You do not need an extra configuration file and you can provide initialization parameters to the servlet, it is a singleton managed object. The only thing that saves struts is the taglibrary, and the support for internationalization, but this does not make it a quality framework.
  63. The problem with Struts[ Go to top ]

    Well said. The main argument against Struts made in the article was that an indirection level for the request URLs is not necessary. This additional level is a consequence of the Front Controller MVC pattern (aka. "Model 2"). There is another MVC pattern, however, which doesn't suffer from this problem: the Page Controller pattern. Using this pattern, requests are targetted directly to the
    Web components that produce the Web pages. Some may say this would be bad for medium to large web apps, but I still fail to see why. Maybe the "Struts-heads" could give us a concrete example that shows when the Front Controller is really beneficial.
  64. The problem with Struts[ Go to top ]

    If the view decides which controller to call, you don't have MVC.

    <QUOTE_AS_IT_SHOULD_BE>
    Is Struts the best choice for every project?
    No. If you need to write a very complex application, with many pages, then you might consider to avoid the configuration of GOTOs in struts-config.xml
    </QUOTE_AS_IT_SHOULD_BE>
  65. The problem with Struts[ Go to top ]

    True. But that's not the case when using the Page Controller pattern.
  66. The problem with Struts[ Go to top ]

    Some may say this would be bad for medium to large web apps, but I still fail to see why. Maybe the "Struts-heads" could give us a concrete example that shows when the Front Controller is really beneficial.

    Simple example. I have a web-app, and there are several screens (or, more specifically Actions) which can result in an order being created or modified. So, I have these Actions forward to /orderModified.do. I'm not sure yet whether I want these actions to take the user to a dedicated order status page, or whether I want it to go back to the user's home page, which also has order status information. And this decision may change a couple of times with iterative feedback cycles from the user.

    With Front Controller, I only need to change the defintion of the /orderModified action in struts-config.xml, and this will make the change throughout the application. If I embed my web component in the page, I need to hunt down every page which contains this component to make the change.

    In short, Front Controller is extremely useful when you want to refactor or redesign your interface.
  67. The problem with Struts[ Go to top ]

    Thanks for the example. If I understood it correctly, the Action that processes the request for /orderModified.do performs (directly or not) the business logic that decides which .jsp (or whatever view component) will produce the Web page that shows the order status (a dedicated page, the user's home page, etc.).

    This same behavior can also be achieved with Page Controller (which, BTW, is also intended to support MVC). You wouldn't embed that business logic in any view file, or have it implemented in many classes.
    In a Page Controller solution, you would simply make a call (the same call), in each of the order-generating Actions, to a class that performs the order status page selection logic.

    In reality, the responsibility to select the next Web page should not belong to the Front or Page Controller patterns. This responsibility should belong to a different component, known as the Application Controller, which can be used with either type of input controller (Front or Page). The terminology and design patterns I am using is described in Martin Fowler's book, "Patterns of Enterprise Application Architecture". In Sun's version of the Front Controller pattern (as in the book "Core J2EE Patterns") these two separate responsibilities (ie., mapping URLs to "Action" classes/methods, and selecting the next page) are not clearly separated.
  68. The problem with Struts[ Go to top ]

    If I understood it correctly, the Action that processes the request for /orderModified.do performs the business logic that decides which .jsp will produce the Web page that shows the order status (a dedicated page, the user's home page, etc.).

    No. This information would simply be stored in an entry in struts-config.xml like so:

    <action path="/orderModified.do" type="org.apache.struts.actions.ForwardAction"
      parameter="/renderHomePage.do"/>

    The decision about where the navigation goes next is not made in your Action classes, or in the Forward Action class. It is in the configuration file, and changing this one line will cause the change to take effect everywhere.

    I would also disagree that this sort of navigation decision can be considered 'business logic'. These sorts of 'pure UI' issues (just like 'pure persistence' issues) should in fact be separated from your business logic code.

    In a Page Controller solution, you would simply make a call (the same call), in each of the order-generating Actions, to a class that performs the order status page selection logic.

    I thought your original question was why request indirection was necessary in Struts. If your point is that request indirection can be done outside of Struts, I'm certainly not going to argue with that.
  69. The problem with Struts[ Go to top ]

    No. This information would simply be stored in an entry in struts-config.xml like so:

    >
    > <action path="/orderModified.do" type="org.apache.struts.actions.ForwardAction"
    >   parameter="/renderHomePage.do"/>
    >
    > The decision about where the navigation goes next is not made in your Action classes, or in the Forward Action class. It is in the configuration file, and changing this one line will cause the change to take effect everywhere.
    > I would also disagree that this sort of navigation decision can be considered 'business logic'. These sorts of 'pure UI' issues (just like 'pure persistence' issues) should in fact be separated from your business logic code.

    Ok, so in your example the order status page is always the same, and cannot differ depending on the page where the user started the action to create/edit the order. In this case, no business logic is needed, indeed. In fact, there is no runtime decision, and the "choice" of page really belongs in the view components. So, one solution (in a Page Controller approach) would be to specify this status page in each of the order entry pages. But as you said, this could get repeated too many times. The solution to this (again, with Page Controller) is to use the standard mechanism for mapping URLs to web resources: configuration in the WEB-INF/web.xml file.

    > I thought your original question was why request indirection was necessary in Struts. If your point is that request indirection can be done outside of Struts, I'm certainly not going to argue with that.

    Actually, my complaint with Struts is that it requires this indirection level for ALL HTTP requests, even though in most cases you simply don't it. Your example is, I believe, the exception rather than the rule. With Page Controller, you can still have the indirection level, but only when actually needed. And when you need it, you are not forced to use a proprietary XML configuration file.
  70. The problem with Struts[ Go to top ]

    Actually, my complaint with Struts is that it requires this indirection level for ALL HTTP requests, even though in most cases you simply don't it.

    No. It is recommended as a best practice, but Struts does not require it. Struts provides constructors for the ActionForward class in which you can embed a hardcoded URI if you desire.

    Your example is, I believe, the exception rather than the rule. With Page Controller, you can still have the indirection level, but only when actually needed.

    Yes, well I think this ties into Alex and Ryan's discussion about whether you know everything about your design ahead of time. :)

    I find it very handy to always use indirection on medium to large-sized web apps because I can't always predict how I am going to refactor or redesign the interface down the road.
  71. The problem with Struts[ Go to top ]

    No. It is recommended as a best practice, but Struts does not require it. Struts provides constructors for the ActionForward class in which you can embed a hardcoded URI if you desire.


    Yes, but I wouldn't want to do that from Java code. If I have a fixed URL, known at UI design time, I want to be able to specify it in the view files, just like any ordinary HTML link. A nice feature of the Page Controller is that when the output page is to be generated by the same .jsp to which the request was directed at, it's not necessary to specify the next page in the Action method (ie., no need to instantiate an ActionForward or similar object). This is great because most pages in a typical web app work like that.

    > I find it very handy to always use indirection on medium to large-sized web apps because I can't always predict how I am going to refactor or redesign the interface down the road.

    Well, this is debatable. The design of some web apps is mostly fixed before Java development (usually by Web designers), and tends to not change significantly after that. In more dynamic cases, remains the question of whether it really is that hard to change the links in a few pages. With an appropriate tool, this may be done in minutes, if not seconds (IntelliJ IDEA's "Replace in path" feature comes to mind). And if you have dozens of pages referencing the same URL, perhaps it would be a good idea to create a reusable page component (to be statically or dynamically included) to centralize that URL.

    I think Struts and the Front Controller pattern are useful, just not as effective or easy to use as a good MVC framework based on Page Controller can be.
  72. The problem with Struts[ Go to top ]

    There is no question that problems that can be solved with simpler technologies are being solved with more complicated ones. Over engineering is a real problem. On the other extreme, you have projects that suffer from no design or planning at all.

    > Struts is a good example of essentially a poorly designed framework that because ...

    I'm not a huge fan of Struts, however I do generally prefer model 2. That said, I have no doubt that a better model 2 framework could be implemented, in fact I could set out to build that framework each time I start a new project. What Struts has going for it, is the fact that it already exists, has been well tested, and it is reasonably easy to find people that are familiar with it. It may not be ideal, but it's there.
  73. Soap Box: Software Fashion[ Go to top ]

    A good article and quite true. I think many developers think the same way what have been expressed in this article. But I see lot of people on serverside.com took it very seriously and started a deep discussion on struts and etc.

    The essence is that, don't make your application on the basis of "FAD" but the requirements (Don't put a rocket engine in your Beatle), it doesn’t' mean that EJB, struts and XP are totally useless. Use it if using it save you some time (including maintenance).

    But I also strongly believe that there should be a limit of using the framework. I think Java API is the most beautiful framework and I personally try to stick with that as much as possible. It gives your code guaranteed portability.

    I also think that since the inception of C#, Java is getting more and more pressure to add new features in the language just for the sake of competition. I think it's totally ridiculous. If you remember Java was a hit then becuase of it's simplicity and ease of use not all the fancy feature a language could have.
  74. Soap Box: Software Fashion[ Go to top ]

    The article makes some very good points. I think sometimes we get stars in our eyes and we get obsessed with a technology or concept. I've seen design done for the sake of design rather than for the good of the program. I've seen XP "experts" swear you must use all the XP concepts or it won't work. That XP is somehow not useful in parts. I wonder how pair programming works when I'm the only developer on my team!

    I cringe a little when I see MVC2 referred to as a 'fad' though. So long as your application doesn't get so broken up that it runs like a hippo through mud, I think MVC2 is a good idea. Again, I've seen apps overdesigned, but following basic MVC2 rules are just a good idea. Especially as I see more and more places go with separate developers for front and back end work. I'm using Tapestry myself just in case a graphic designer is ever hired. By not mucking up my view I can easily transition some of that work to someone better suited to aesthetics than I am.

    What's the reverse of agile? Clumsy? I think that's not an unfair description of how some programmers prefer things. I'm not saying XP is king, I've seen it implemented horribly before. At the same time, shouldn't the people writing the programs get better about communication with end-users? Is it really possible to get it right on the first shot? I'm developing an app right now with really loose requirements. I don't think they really know what they want, so I'm not about to get married to my code. They're not technical people, they don't really understand.

    I don't look at it like carpentry. I think a better example would be building a car. There are car people and then there are people who just know how to drive. Your casual user probably doesn't know if they want a short or long throw gear shift. They may not really understand the ergonomics of a dashboard and how they want things to fit together. Yet they might sit in a car and think "something's not right". A car expert could tell you right away and know what they want on the first shot. However, not everyone who drives is a car expert.

    If everyone was a technology expert, I'd be out of a job. It's bad enough that so many people already do think they know computers because they cracked their case once or they opened an .ini file. The only way you can get the requirements right on the first shot is if the people giving them to you understand technology as well as you do.

    I do think Struts went overboard. I was initially excited, but it turned out to be more trouble than it was worth. Yet so many people blindly throw themselves behind it.

    I think a lot of negative reaction to the article here is due to the fact that most developers are followers and not visionaries. No one wants to think they've fallen prey to a fad. I'll admit it. Struts, XP, and EJB's. Hey, sometimes things take a little playing with before you realize what they're really good for.
  75. It is a good practice to spate the presentation layer from the data layer, with or without MVC. I think a software engineer would agree.

    Struts is a light weight implementation of MVC and by far the most popular framework because it is simple and powerful.

    I use it with iBatis DAO, JSTL and Display tags. There is now faster way to develop a web app AFAIK. All are open source and operating costs are low.

    I have to guess, without being flame-y, that if someone can’t succeed with Struts, they just can’t succeed. The only people that do not like are vendors, because they can’t charge for it but have to support it, to bad. I do a lot of public and private training with Struts, so if you want to learn best practices, track me down at baseBeans.com. I can run circles around .NET guys with Struts.

    Come knock me down of my hill,
    .V
  76. I wanted to stay aside from this flame war, but this comment just makes me reply:

    > I have to guess, without being flame-y, that if someone can’t succeed with Struts, they just can’t succeed.

    I am sorry, but this is plain ridiculous and presumptuous. Struts does a pretty good job in terms of MVC, but it is really limited when it comes to true modularity -- Struts pages are completely monolithic (Tiles notwithstanding, but it is quite limited by itself as well) and doing more complex UIs essentially degenerates into a fancy variation of copy-paste. If you say this is incorrect, perhaps you can explain why the Struts designers are so involved with JSF, which attempts to resolve precisely this problem. Or perhaps you can look at client-side UI libraries and explain why they have the notion of "component" and Struts does not.


    In general though, as a person looking from the sidelines, I have to say that this whole discussion is very strange. Alex seems to preach horzontal separation through OO, other people seem to preach vertical separation through MVC, while it seems to me that doing both is quite possible (e.g. by using Tapestry, not Struts) and that by using both you get the best of both worlds. I do not see why the two approaches are competitive (although I would agree that Alex must be very lucky if his requirements do not change).
  77. <Mind Bridge>
    Alex seems to preach horzontal separation through OO, other people seem to preach vertical separation through MVC, while it seems to me that doing both is quite possible (e.g. by using Tapestry, not Struts) and that by using both you get the best of both worlds. I do not see why the two approaches are competitive
    </Mind Bridge>

    Earlier, I've posed the question here that no one seems to want to tackle: why, if OO technology appears, by general consensus, to be the best way to achieve separation of concerns, do we need additional crutches and training wheels and wheelchairs in the form of Struts and other web frameworks? If I already manage to fully achieve separation of concerns, why do I need to put on some extra fluff on top of it? Seems to me like a pointless, dumb exercise in following the hype blindly, just because the guy next to me, and his friends, and the people they know, are all doing it.

    Or, more pointedly, I pose the question to you: why do we need the best of both worlds, if one world (i.e. OO) is already the best? If any of you guys did some scientific research before you slid into this software development sludge, you would've no doubt been aware of the principle of Occam's razor, which states that it is vain to multiply entities in order to arrive at the solution. However, maragaritas ante porcos...

    <Mind Bridge>
    although I would agree that Alex must be very lucky if his requirements do not change
    </Mind Bridge>

    I am not lucky, I work very, very hard at it. You cannot achieve stability and reliability by accident or blind luck. Majority of my efforts in software development go towards establishing what I like to call Quality Before Design. Even before we start designing the solution, we must arrive at the quality. Only when we have clearly established what is it that our customers regard as quality (which, believe me, does not always coincide with what the open source community regards as 'quality'), would we tackle working on building it. Most people who are whining and slobbering here how I live in a different universe have never even heard that such a thing as 'quality' is even possible. Having been immersed in their daily arm-wrestling with the ugly low level code, they don't believe when someone tells them that there is a better way. Oh well...

    Anyway, once you arrive at the quality (and it's by no means an easy task, it's actually much harder than building large scale software systems), you have finally established a firm foothold. If you then deliver a solution from that foothold, you'll discover that your customers will find it acceptable, even desirable, and will not continue pestering you with requests for upgrades and modifications. Most of the time, when customers complain and keep coming back with a bunch of "if only..." requests for modifications, it's an unmistakeable sign that the product hasn't actually addressed real and fundamental goals. It's important to realize that customers can't articulate those goals for us -- we need to do the due dilligence work and articulate the goals for them, by carefully analyzing what is it they are trying to achieve. Most people work on something and are definitely pursuing certain goals although they could be blissfully unaware of those goals. Therefore, it would be naive to expect the customers to be able to clearly articulate what is it that they really want.

    Of course, as is the nature of any software, bugs do creep in, and we must address those, but fixing bugs is a different type of activity than upgrading and evolving a half-baked software product.

    Of course, if I may be so bold to make a prediciton here, looks like some people who will read this will (again) have trouble parsing what I wrote here, and will (again) invent things I've never said, or overlook important things I've plainly said. To those people I'd like to make on suggestion: please try reading my explanations with the brain installed. Try that, just for a change. Give it a world, it may make a bit of a difference to you (of course, even with the brain installed, your mileage may vary:-)

    Alex
  78. \Alex B\
    Earlier, I've posed the question here that no one seems to want to tackle: why, if OO technology appears, by general consensus, to be the best way to achieve separation of concerns, do we need additional crutches and training wheels and wheelchairs in the form of Struts and other web frameworks? If I already manage to fully achieve separation of concerns, why do I need to put on some extra fluff on top of it? Seems to me like a pointless, dumb exercise in following the hype blindly, just because the guy next to me, and his friends, and the people they know, are all doing it.
    \Alex B\

    Here it comes again - the way I parse the above is that you're saying that the only tool you need to solve your problems is OO (presumably as captured in the Java programming language).

    Do you ever use 3rd party libraries? Are there any .jar files in your application besides your own? Do you roll everything yourself?

    What Struts is is a 3rd party library which tackles a specific problem in web development. It's nothing more or less than that - a library which can you use. This is not "extra fluff on top" of OO - it's just a library which gives you certain capabilities out of the box.

    The real issue here seems to be a variant on "Not Invented Here" syndrome. And when I say that, I'm not trying to put words in your mouth - it's my observation of what really bothers you about packages like Struts. As I said in an earlier message - are there _any_ 3rd party packages that you like? Or do you just reject any code not written by your own hand as contemptible?

    \Alex B\
    Or, more pointedly, I pose the question to you: why do we need the best of both worlds, if one world (i.e. OO) is already the best? If any of you guys did some scientific research before you slid into this software development sludge, you would've no doubt been aware of the principle of Occam's razor, which states that it is vain to multiply entities in order to arrive at the solution. However, maragaritas ante porcos...
    \Alex B\

    Well, beyond the silly reference to O.R.....why do you insist that there are two worlds? Frameworks such as struts are not external to OO - they _are_ OO, and are an OO approach to solving a certain class of problems.

    \Alex B\
    I am not lucky, I work very, very hard at it. You cannot achieve stability and reliability by accident or blind luck. Majority of my efforts in software development go towards establishing what I like to call Quality Before Design. Even before we start designing the solution, we must arrive at the quality. Only when we have clearly established what is it that our customers regard as quality (which, believe me, does not always coincide with what the open source community regards as 'quality'), would we tackle working on building it. Most people who are whining and slobbering here how I live in a different universe have never even heard that such a thing as 'quality' is even possible. Having been immersed in their daily arm-wrestling with the ugly low level code, they don't believe when someone tells them that there is a better way. Oh well...
    \Alex B\

    I'm sorry, you have completely lost me. If I may paraphrase - you're saying you achieve some sort of "Quality" before any design is created, before any code is written, and that this "Quality" is where most of your effort goes. And is the bedrock upon which you build the actual system.

    The problem is - you don't specify what it is you create in this stage (beyond calling it "Quality"). What are the _concrete_ physical things which come out of this stage? How does this stage help the developer? How does it help you?

    I'm sorry, but I've read that paragraph over and over again and still have failed to find any meaningful content within it.

    \Alex B\
    Anyway, once you arrive at the quality (and it's by no means an easy task, it's actually much harder than building large scale software systems), you have finally established a firm foothold.
    \Alex B\

    What is this mysterious "Quality" thing you keep talking about? You say you've arrived at this thing - what is it? What do you have? What is this thing that you've worked so hard at - so hard that "it's actually much harder than building large scale software systmes)."

    You may not realize it, but you're talking around the issue here. You go on and on about this stage of your own software lifecycle, and yet have imparted zero useful information about it. This isn't sarcasm or a jibe at you - I seriously have come away from this post with no idea at all what you're talking about.

         -Mike