AMEN! Less Code <> Simple
In my experience, over-complexificationialzing in the name of writing less code always makes for more cost. Larry On 12/2/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Preach on, brother Rick! :) > > I think your arguments about simplicity are very cogent. I think too > often, people mistake having to do less work for something being more > simple. Simplicity, to me, is being able to fully understand what it is > I'm doing, not necessarily having to do less of it. This is the failing I > see in a great many things we're all playing with today, be is JSF, JSTL, > Struts, Spring, Hibernate or any of 100 other things we could all name. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > AIM: fzammetti > Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > > On Fri, December 2, 2005 3:11 pm, Rick Reumann said: > > Don Brown wrote the following on 12/2/2005 12:44 AM: > >> When we started Struts Ti, it was conceived as a new > >> framework that aimed to simplify the developers life requiring no > >> configuration, > > > > What??!!!! No configuration? You mean you aren't using the Spring/ EJB/ > > JASS/ RMI/ Hibernate/ JMS/ Struts/ Maven/ XDoclet/ Ajax/ AspectJ/ > > WebServices/ 1050 XML confif files/ KitchenSink solution? That framework > > must suck. > > > > But all kidding aside, that's my biggest complaint right now with Java > > solutions that seem to be pushed - Too many 'extra' parts that you need > > and lack of good documentation and/or examples in getting started. > > > > Even when I taking my first stab into JSF a few months ago, I was quite > > annoyed with having to go to several different web sites to get what I > > needed, and even then, there was little documentation on how to > > integrate everything. Now granted Craig and the others on the MyFaces > > list were more than helpful, but I certainly can see how someone new to > > choosing a JSF solution would be really overwhelmed. You don't just go > > get "JSF" - you have to get a JSF implementation like MyFaces and then > > also probably get Shale. But regardless, look how difficult the process > > is... put yourself in the 'newbie' shoes. You hear the buzz word JSF so > > you decide to google it. Go ahead put in "JSF" in google. What do you > > get? Well one of the hits near the top is JSFCentral so you go and click > > on that link http://www.jsfcentral.com/ That home page doesn't help > > much for just getting started, you try some other sites (ignoring the > > military ones). Next there is one on JSF-Spring.. newbie thinking "Oh > > great, more confusion, I need to use Spring with this?." Well scroll > > though the Google results yourself and start clicking on some links - > > It's darn confusing to someone wanting to try and use the technology. > > "Hmmm there's this Oracle stuff, there's this MyFaces stuff I keep > > seeing... Hmm there is Shale stuff and I see Spring mentioned." I > > understand JSF is a reference and not an implementation but I'd love to > > get some focus group surveys going on with 'new developers' and give > > them a day to explore the web with just the question "Figure out how to > > get started coding a JSF application." > > > > Even the examples out there for JSF applications aren't that great. Even > > the MyFaces ones often break (hit the browser refresh button when going > > through them). I understand, as has been mentioned numerous times > > before, that JSF take a different mindset. To quote Craig: > > > > <quote> > > Fundamentally, in the Java-based web application architecture space, two > > schools of thought are emerging as very popular ... an "action framework > > based approach" (Struts 1.x, WebWork, Spring MVC, ...) and a "component > > based approach" (JavaServer Faces, Tapestry, ASP.Net, ...).' > > </quote> > > > > I agree that both are viable and *I actually do LIKE* JSF - I'm not here > > to bash it and I look forward to watching it progress. I would disagree > > though with the statement that I believe many in the latter camp above > > are claiming: that JSF is 'easier' to pick up for a newbie. I'm not > > going to say that it will be 'more difficult' to learn, but I wouldn't > > say it will be easier either. I guess if you know Zero about the servlet > > api (basic request/response) stuff and you are using a JSF GUI designer > > tool, then yea, for a basic app, I'm guessing JSF might be quicker. Do I > > have empirical evidence to make this claim? No I do not. However, I've > > worked with people over enough time on the Struts list to notice where > > most of the questions come from. I still firmly believe that once we see > > a lot of 'average-to-new' developers coding with JSF, that we'll see > > just as many questions as you see new struts developers post. I > > obviously can't state that as 'fact' but I'll be willing to bet that the > > learning curve will end up about the same (assuming little Servlet > > programming experience.. if someone has a decent amount of JSP/Servlet > > programming experience, I'd actually tip to the side that Struts will be > > easier to pick up). > > > > I sort of digressed a bit with my above JSF comments. My point was that > > I'm frustrated with the current trend that seems to push for the > > inclusion of more and more 'stuff' into J2EE applications. Sure, some of > > it is necessary, but some of it isn't. (Do I really need 50 Factory > > objects in the event my web app becomes a Swing app in the future? Do I > > really need 25 layers and 30 XML files to get to a DAO? Do I really have > > to be injecting so much stuff at runtime?). > > > > It's sort of funny.. for the heck of it, I pulled out my old JSP book > > "Web Development with JavaServerPages by Fields/Kolb (Manning)" and > > looked back at their simple example of a web application. The example > > has one main servlet controller you submit to and you pass in the > > request the name of a Command object which gets looked up in a Map and > > execute called on it. Basically, in a sense, the concept isn't much > > different from Struts. Someone that understands Java and understands the > > Servlet API can see what's going on very easily. THIS is my big sticking > > point with some of the new technologies. What is "going on" beneath the > > covers becomes so far removed from the developer that I think we end up > > making things more difficult instead of easing the burden on developers. > > I could be totally wrong of course, but it's just my current perception. > > How many times have you started coding using a new technology > > implementation and you couldn't figure out why something wasn't working > > right. Your options become a) google b) keep trying different things c) > > ask on a mailing list or d) get out your debugger and start going > > through a million files that are contained in the jars you downloaded > > and hope you don't have a lot of injection stuff going on. > > > > Don't get me wrong, I like using open source technologies to aid me. I > > really don't feel like going back to coding JDBC by hand. I don't want > > to be typing out.println(" ...") or even <%= %> in a JSP either. I do > > tend to think, however, that Java apps many times tend to be bloated > > with "too much" stuff. For the past three months I started working on a > > client side (windows forms) .NET app written in C# and I have to admit, > > other than the lack of some nice logging functionality, I was blown away > > by the ease in which most everything was *there for me* provided by the > > .NET framework. It was very nice. > > > > This is why I was always against the idea of removing things from Struts > > like Tiles (when talk of that was buzzing around). I don't think most > > new developers enjoy having to hunt around the web in order to find > > components they need to really make the progress they want. I also don't > > think the framework should 'require' their use or prevent someone from > > using a third party package, but the basics should all be there for > > quickly getting started. > > > > > > -- > > Rick > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
