newbie: Choosing web framework
I'm developing a web application, but come from a hardware background. I created a design document and am contracting out the foundation so that I have a solid platform to build on. That way I later don't have to redo a poor hack do to my inexperience. The contractor I like the best has recomended using:
- Templating: SiteMesh
- Controler servlet: Struts
- Services: Spring framework with Acegi Security
- Data Access: Hibernate
I have been reading Manning's "In Action" series on the frameworks, and while I'm very impressed, I am a bit unsure as to whether Struts should be used at all. It seems as if its being transitioned out, with JSF as its replacement. So I have a few questions:
- Should Spring also serve as the controller rather than Struts?
- How easy would it be to later transition from Struts to JSF, once JSF is more common place?
- Are there any other issues I should be aware of?
Thanks for the help!
It all really depends on what you are trying to do with your web application. How "applicationish" is it? Different web frameworks suit different kinds needs.
While Struts will be with us for a while, I think there are much better choices.
Can a Struts app be converted to JSF? Sure. But they are conceptually different so there will be some effort involved. I would look at Shale if this is your plan.
Spring is an application framework while Struts, etc are web-ui frameworks. So you probably would be well served by using Spring no matter what UI framework you use. Spring does come with its own Web MVC UI framework and I have heard good things about it. Again, what you use is really determined by what you are trying to accomplish.
It makes me wonder when the contractor put Spring under a "Service" heading.
I think I finally understand how everything fits together and interacts, thanks to skimming about a dozen books. My web app isn't trying to be a rich client that feels like a desktop app. The image attached helped me understand the flow, except replacing WebWorks with Struts in my case.
From what I've read, Spring MVC is less capable and robust than Struts is, but was made more to fill in a gap in their framework. Mostly their focusing on the application layer and have integration code for Struts and JSF.
Craig McClanahan (founder) says that using struts-faces, it should be relatively painless to transition to JSF. You change page by page, until your done, and have no interoperability problems. Its just bad if you never complete it, since then you're using two frameworks and going to confuse developers.
I think the contractor put Spring under Services more for my benefit than anything else. So I'm not concerned.
Glad you've got a handle on it. There is a lot to know and understand and even those with many years of experience in the industry w/ good Java experience have trouble getting a handle on it.
If you think you are going to move to JSF, you might as well do it now. JSF is definitely usable right now. If you check out what Craig has to say - the struts-faces is for current Struts projects.
I wouldn't say Spring MVC is less capable than Struts. It is for solving different problems. Struts can be a pain if you use it for the wrong thing. I know some people who have a strong Struts background and really like Spring MVC (vs Struts).
It sounds like you have a web site with some application functionality (not really a web application). If so then JSF would be a fine fit.
The diagram is pretty good. I would say though, that the IoC containter surrounds the whole thing. It isn't embedded in the UI layer. Well maybe it is in WebWork, but it shouldn't be. The purpose of IoC is to allow you to wire the different layers and different technologies within the layers with out creating dependencies.
You are right about the IoC issue, I noticed it too but didn't really pay much attention to it. I'll probably make my own version with some changes for future design docs, since I find myself more productive fully planning ahead than straight coding.
Since the contractor doesn't have experience with JSF, I don't want to pay him to learn it, and there are a lot of other issues to deal with I'm going to hold back. I'll set my goal to make the transition in version 2.0-3.0, where my application won't have become so mature that I'm simply overwhelmed with the change-over. Plus, by that time I should be comfortable with all the technologies and have some experience.
My application fits somewhere between a web application and a thick client. Its a strategic management system, so for my goals being web-based is key. However, it will have a lot of analysis and graphing capabilities, so its not just another e-commerce or dating site. I think JSF would be a great fit, and luckily most of the complex features won't be integrated until versions 3 - 5.
Thanks for the tips, its really helpful hearing someone confirm your suspicions.
I actually have a few other issues with that diagram.
Just a note. Web application is a broad term. I avoid it because it can mean so much. A Java Web Start app is a "web application". It can also be a thick client. I try to avoid the technology and define what is doing instead.
How I develop applications - I create applications that might have a browser ui and/or a desktop ui and/or and/or a commandline ui and/or no ui.
I understand that you don't want to pay the contractor to learn. But in this business, that is what we do. Constant learning. If your contractor is good, he/she will have no problem in picking up JSF (and neither should you). Effectively you are putting of the cost till later (the old Midas muffler commercial). If I understand you correctly, it sounds like JSF (or something like it) would be a good fit for your app. And doing the UI with struts will create alot of additional work because of how it will have to be done.
Some technologies you might want to look at for your specific type of application (strategic management system)
BIRT or JasperReports
Thanks for the project names, I hadn't heard of any of them before. I'm taking a different approach than Pentaho (and the companies it's copying from), but it'll be a good source to get ideas from. I don't plan on incorporating similar features until version 3.0 or 4.0, since I had a lot of unique aspects to add first.
You're right about being willing to learn, which is why I'm reading everything I can on the frameworks so I can begin doing some development work too. I talked to the contractor about it, his feeling is that Struts' main benefit over other frameworks is the extensive set of taglibs that make Struts Actions and ActionForwards fairly straightforward. It also has active open source development support and lots of developer knowledge. In comparision, while JSF has a lot of corporate backing and a newer design, it lacks developer knowledge, open-source support, and a comparable library. His rememended taking the following course:
Based on my past experience, one of the first things that you are going to want to "fix" will be the UI layer. As you use this, other folks use this, and feedback is gathered there will be things that need to be "fixed". Once there is enough to warrant a bit of UI work then we can use Shale to leverage the investment in Struts / Spring and just replace the "view" (Struts JSP taglibs) with JSF and migrate away from taglibs toward JSF controls.
He was willing to switch to JSF, since he's familar with it. After careful thought, I decided to follow his advice. Thanks for all the help, I really appreciate it. Its helped me learn a lot.
Well, have fun and let me know how it goes. Hopefully you will get to spend some time in the code and maybe you'll see some of things I have seen with Struts, etc.
Just a note. Struts does have an active development support, but it has gone back burner. Also, there is plenty of open source support for JSF. I have at least one application that uses JSF and uses no commerical JSF components. And the libraries are more than enough to support what you'll do.
But it does seem your contractor is more knowledgeble on Struts and not much on JSF and you do have a good plan. Again, let me know how it progresses.
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center