I may not be the best person to address your concerns, but I'll give it a shot.
In our shop we've developed applications that have several hundred components and screens. There is no "out-of-the-box" installation for us. No two clients desire the same behavior and customizations on the fat client/server apps are expensive and take forever. We were always looking for ways to externalize screen flow and component flow from the code so clients could configure the app and build custom solutions. I say this because I don't think these issues are unique to us, but fairly common in large application development. (If it is unique to us, then I assume we're doing something wrong.) Along comes J2EE and MVC with a nearly perfect environment for that. It turns out that, because of executive decisions, we're not using Struts, but our stuff looks amazingly similar to Struts ;-) See comments below: > -----Original Message----- > From: Jean-Philippe Bret > Subject: web-MVC-frameworks in question [Was: Struts vs. other > Framworks.....] > > > I'm not really convinced by all these frameworks, mainly because > of the importance of the declarative-construction of web-apps : > these fwks use xml or property files (or even better data bases...) > to tell the FrontController "which class takes care of this URL" > (e.g. "/my/first/action/url" = "my.class.for.FirstAction") and > "where he goes from there?" (e.g. "ok" = "url1" ; "ko" = "url2") > Declarative construction is key to an MVC framework. Part of a controller's decisioning process involves where to go next. It quickly becomes obvious when you are hardcoding these things that it's not a good idea. In a web world, what if someone changes the name of a JSP? It's much easier to modify a configuration file than change code. More importantly, adding new functionality involves less coding effort. You write the component (Actions in Struts), write the view, and quickly integrate the component with the application. Further, I question why the database is the better solution (assuming you mean an RDBMS). Controller configuration data is typically flat or hierarchical, and it doesn't make a great deal of sense to me for that to be stored in an RDBMS with all your application data. LDAP's work well for this in larger systems, and XML can work, but I agree that administration concerns are valid in a large application. In a small to medium-sized application, XML is not a problem. It's a universal language. You make your edits and you're on your way. But at some point it crosses over and becomes a large hassle, especially if system administrators who want GUI interfaces have to handle it. But I don't think Struts should feel obligated to provide GUI administration. We, for example, wouldn't use it because our large application admin requirements are unique just like everybody else's are. > - isn't this process too heavy for a wide and often-changing-content > web-app (these fwks would have to come with a site editor that > could help web-app-masters organize their application site and > work-flow - but they don't seem to come with any tool) ? > Actually workflow engines exist and are being created that allow very complex configuration of such things based on decisioning processes. This is a requirement for our applications -- that a customer could assemble our components via a workflow engine and build apps that we've never dreamed of. But I don't think MVC is the right tool for providing access to "content". It's an application framework, not a content manager. It is very helpful in providing access to functionality, and controlling flow. Use Struts for the "application" sections of your web app (i.e. shopping carts, searches, etc.). Use other appropriate means to access the content. > - why not using code-oriented web-app structure (just as doing > listeners and custom model-objects) ? > You could argue that Struts does use a code-oriented structure (thought I'm not convinced that I understand your model). You never have to dig into struts-config.xml from your code. You get to it through the ActionMapping framework. That framework could be extended to get its data from an LDAP or even database if that was a requirement. I wouldn't want anything more code-oriented than Struts because all of Struts' configuration is code-oriented except the data itself, which you would want to be externalized in a large environment. > - do you feel these fwks are reliable for others media (voice, wap...) > Not really sure, i.e. I haven't done that. However, you probably want the media to be delivered over HTTP, so the J2EE approach would still work. However, audio and video media on the web tends to be more static. What I mean is that you would probably provide static links to it on your site and let the web server handle the streaming instead of pointing an action or component to the media. If the media is dynamic -- generated on the fly or something, then Struts is still a valuable solution in my mind because it's just a component-based pattern for accessing your application functionality. I'm not sure what has to be done to stream media over the HttpServletResponse, though. > Moreover, I found another problem that isn't clearly addressed > in any fwk (maybe I haven't seen it) : the ability of controlling the > client behavior that can become hardly manageable (thanks to > beloved HTTP/HTML...) > This really has nothing to do with Struts or MVC, but with web development in general. Since our apps are mostly intranet instead of internet we can dictate the client environment a bit more. We rely on IE's DHTML support because Netscape is such a pain to work with. For customer-facing internet applications, we can't dictate the browser so we test the majors. In those cases validation is more server-based and other usability issues come into play, but they are the same issues users face on all web sites. IMO, if you're going with a web app implementation, J2EE/MVC is the best fit. It's flexible and configurable. It provides great separation of logic, and it's easy to scale up and easy to customize for differing delivery mechanisms. Again, if you're looking for a "content manager" MVC is probably not the way to go. Those are just a few of my thoughts. Greg -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
