On Thu, Jul 25, 2002 at 10:40:25AM -0400, Jeff Duska wrote: > > Here is my 50,000 ft overview. > > All the frameworks use the same design. They create a front side > controller. You read more about that here @ > http://martinfowler.com/isa/frontController.html. You can find a very > simple example in Forums demo application.
I would agree, these frameworks are more similar than different. > First of all, Struts is the king. This is because Struts is supported by > Sun. Thus, there is a lot of documentation, books and tools for it. I True. Unfortunately it's also overly complex, heavily biased towards JSP, and fairly rigid in how it defines the model. > would say that WebWork appears as mature and as feature rich as Struts. > Maverick doesn't seems to have the same level of depth and breadth that > Struts and WebWork. It is up to you if this is good thing or not. The > advantage is that you'll get up to speed quicker with Maverick than > Struts or WebWork. On the other hand, Struts and WebWork have additional > features and tools that you will not have with Maverick. The main reason That's an interesting perspective. I'm curious, what features? The big piece "missing" from Maverick is a tag library - which is deliberate. Not only is JSP simply one of many possible templating languages, but the JSP Standard Tag Library (which works great with Maverick) pretty much obsoletes most of the Struts and WebWork tags. There are some other bizzare things in Struts like a database connection pool, but I think it's pretty safe to say this is a pretty silly thing to put into an MVC framework. Since Maverick is a minimalist, modular framework, it's actually possible to do some interesting things - including use Struts Actions directly without modification. Given that, it's possible to use any validation or form processing code written for Struts. It's tempting to try to make an argument that Maverick offers close to a 100% superset of the features of Struts - if only because you can incorporate Struts pieces if you really needed it. Maverick does offer several important features which neither Struts nor WebWork come close to addressing: . Transformation pipelines for each view . Automatic internationalization and browser customization > to choose Maverick, IMHO, is if you need the transformation features. > This is a really neat feature no one else has. My big problem with all > these platforms is that Velocity is a second class citizen. This isn't > as much of a problem with Maverick, but with Struts and WebWork several > features are accessible only via a Tag Libraries. There nothing stopping > you from getting these working with Velocity, but it will mean you have > more work. Or worst, you'll mix JSP code with Velocity. Yuck!!! Since we're doing a compare/contrast of MVC frameworks, I should point out a significant problem with WebWork - it has a very nonstandard way of conveying the model into the view. The "ValueStack" is novel, but very difficult to integrate with templating systems other than the special JSP tags shipped with WebWork. The Velocity and XSLT integration is far from mature. By contrast, Maverick uses the same vanilla VelocityViewServlet that Struts uses to integrate with Velocity. > JPublish is interesting, because it supports only Velocity. The problem > is that is clearly not in same league of the Struts or WebWork. It looks > like Maverick is also step above JPublish. As much as I love Velocity and try to use it as often as possible, it is frequently not an option. Here at Maxis/Electronic Arts, it simply is not an option to use something other than JSP. Even the MVC approach was a tough sell. At least JSTL makes it livable. But why tie a framework to a particular templating language? The MVC logic should be the same anywhere. Sometimes it makes sense to mix and match templating languages, too. Not all code originates in-house. I have a Velocity project at home into which I will be integrating Jive forums soon. I fully expect to be using JSP skins simply because somebody else has already written them. Maverick, being templating-language agnostic, will have no trouble with it. > Then there is Turbine. Turbine is the project or tool we should all want > to be using. It is my understanding Velocity started life as the view > technology for Turbine. My problem is that Turbine is mess. The project > is all over the map. Unlike Struts or WebWork, the Turbine sub-projects > have little to do with web development. It just looks like case of Not > Invented Here! I could be wrong, but I spoke to many people they have > same impression. The website is confusing and document is disappointing. > It is really shame. There is some great technology, Torque and core > Turbine, that is being overlooked, because it buried here. Turbine seems to be really hard to get a mental grasp of. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
