This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
If you use spring which MVC frameword is better ?(struts or tapestry)
As someone has already mentioned, there is no clear answer to your question. It very much depends on the nature of the application and its size along with scalability requirements. Generally there are 2 types of Web frameworks - the action based ones like Struts, Spring MVC etc. and the component based ones like Tapestry, JSF etc. Mix and match is also possible - hence u can guess the complexity . I had done some blogging on this - hence the shameless plug here.
struts is crap, it's just popular because it's old and a lot of managers like stuff like that despite how lousy it really is
tapestry is weird - i read somewhere that a big thing behind it's design was to keep the web pages like html, so the html designer can still have her syntax coloring. and to do that it makes the java programmer do a bunch of weird stuff. also it's a component framework, which is like putting a square peg in a round hole. it's weird i didn't like it, but maybe you will.
i went through this same thing a while back and finally settled on stripes. http://stripes.m4cj.org - and let me tell you what it is beautiful. i couldn't have made a better decision.
i looked at them all (well almost all i guess ... every 10 mins someone comes out with a new java framework) and stripes definitely was way ahead of the curve. the big reason for that is how it leverages annotations. stripes is a lot like struts (same sort of patterns within it), it's just newer and makes a hell of a lot more sense.
Moved this thread to the architecture discussion forum (where it actually belongs).
As for what should be used - struts or tapestry - seek the forum. The debate is a long one and it's not really fair since tapestry uses a different architecture then struts - they have different concepts and all in all belong to different time 'zones'.
1. non-surprisingly it uses Hivemind ( *embedded* IoC container) where the DI happens based on a CGLIB code enhancement of your abstract classes making the later quite difficuilt to unit-test
2. the API is bound to the HTML only. You could find a method description like: "this method prints out the text in RED"!!!
3. All *low-level* servlet-API objects are wrapped into some bizzare tapestry classes, which appear to be almost useless.
4. The promised ease of HTML-coding wears out immediately, if you start divide you templates into re-usable parts. For a Java-unaware web-designer it turns into a nightmare, as soon as he would need to mock each and every module.
The conclusion: the tapestry is good only for trivial HTML-based apps.
Unfortunately, we are employing it now, but I'm struggling to getting rid of it and switch to Spring MVC + WebFlow.
I'll stick up for Tapestry (a bit at least). It has problems, but I don't think the ones that Injecteer mentions are terribly significant. Unit testing is actually quite easy with the tools provided by Tapestry / Hivemind, and in fact it is easier given the abstraction from servlet domain which gives the "bizarre tapestry classes" some context.
However, I totally agree that HTML templates do not deliver on the advertised goals. Any reasonably complex component or component library will quickly bring the HTML back into the domain of the Java developer again. Plus it doesn't even produce valid HTML, except possibly against the very loosest DTD, which these days is a drag.
The most interesting feature of Tapestry is shared with JSF, viz: it is a component-based, event-driven architecture. This should be enough to make anyone sit up and listen. Unfortunately I think there are some problems with the way that Tapestry is implemented, but that is not to say that the idea is bad.
And Webflow could be the answer to all our prayers, I guess. Or maybe JSF. Or both.
well, I agree with David, that those tapestry's probs are not very significant, but annoying.
Recently I took over a wep-app, where the front-end is written in tapestry. That looks, umm... strange.
Imagine, you have a single hige and chaotic JSP page, where there a lot of java-code, that accesses all your services, including the database directly. Then, the whole mess is converted into a tapestry structure, and the *funniest* point here, that the mess REMAINS! For example the following objects get injected there via DI:
- a couple of DAO's
- a hibernateTemplate
- a TransactionManager
- the Spring context itself!!!
the other pages (40+) have pretty much the same layout.
So, after looking at the system, I got a feeling that tapestry doesn't really encourage developers to write nicely layered code.
Another major drawback is that the MVC's Model and Controller are tightly bound together in tapestry. That means that the controller gets bound to the HTML and tapestry's UI-elements.
Another concequence is, you cannot change not only the media/format, but also the presentation technology.
Another limitation of a controller I saw in an implementation of a wizard. The guy to enable sequence navigation put something like:
pageBean.setPage1( false );
pageBean.setPage2( false );
pageBean.setPage3( true );
pageBean.setPage4( false );
pageBean.setPage5( false );
and had to repeat it on every wizard's page.
I'd use an existing wizard-enabled controller here, like Spring's one, but with tapestry you cannot use a controller and view technology other than tapestry's own ones!
btw, some more about those 'bizzare tapestry' wrappers. A simple example: in my web-app I have 2 tapestry servlets, serving two independant sub-apps. Then I had to set a non-default session timeout for one of them.
In a plain servlet I'd make it with session.setMaxIncativeInterval(), but in the tapestry wrapper this method is not available. So, I had to split the web-app in 2 applications only to enable different timeout values.