Personally, I found that using the Spring/Webwork/Maven combination to be a pretty sweet set of frameworks to develop for. There was definitely a huge learning curve (see misc. project presentations on others experiences), but once you get past that, they provide great flexibility.
Maven provides a lot of heavy lifting capabilities... It lets you take this one file, pom.xml, and via its magic, all external code required to build and deploy your small module is automatically lifted from the Gnizr servers, your code is automatically compiled, and any files you generate are overlaid on top of the delivered code and automagically built into a war file (the standard for deploying web services). And I know from personal experience, manually compiling Java stuff/Tomcat stuff and trying to build a war or jar archive can be pretty daunting if you are trying to do things manually.
Webwork gives us a nice Model-View-Controller implementation to work with, supporting different languages for the view aspect including JSP and FreeMarker Templates, and tying into Spring for dealing with Singleton/DAO objects and friends.
Spring makes it nice and easy to pass common objects into other objects, and control initialization of different things magically via XML, and with Maven makes it easy to extend the existing spring xml w/ new xml.
For a simple project, Spring+Webwork would probably be overkill, but for a system designed to evolve over time and be used and edited by many users, I think it (or something similar) would be essential for organizing things in a sane manner. Maven on the other hand would most likely be useful in projects of any size.
Subscribe to:
Post Comments (Atom)
1 comment:
The stack we ended up using for this project was more of a mixed bag for me. I certainly can see where it would come in handy, theres a ton of Java programmers out there, and it definitely provided a lot of useful tools. But I just think that its way, way too heavy for a web software language. I mean, why do we have scripting languages? They facilitate easier and more robust data processing routines, they're lightweight, theres a whole host of reasons. And it usually happens that a lot of the places that scripting languages are better are exactly the kinds of things you're trying to work with in a web environment.
The code for gnizr just felt extremely heavy, convoluted, and overly complicated to me. I've been doing rails stuff for a while and all I could think during the project was how quickly this could have been completed in rails. Some of it is just a more clear organizational path; you have one group putting together one toolkit, instead of this system, which feels like they just took a bunch of lego bricks and snapped them together. Some of it has to do with just the sheer disorganization of the project structure. And then you throw in the advantages of a system like rails where you're really focusing on making the data backend easy to deal with, to the point that you really could get away with not even writing any sql, and its becoming a no-brainer for me.
So, I can see how this system might work really well for some people, and I mean, it really could have been a whole lot worse. I just haven't found any large value in using this Spring/Webwork/Tomcat/Maven Frankenstein-like concoction of a web framework, especially when theres just a ton of mature, robust frameworks already out there.
But thats just my 2 cents ;)
Post a Comment