On 9/2/05, Don Brown <[EMAIL PROTECTED]> wrote: > In my opinion, Java web frameworks > have been too much about how great they are (navel-gazing), and not > enough about making it easy for the end developer. I see Struts Ti > zeroing in on creating a great end-user framework, collaborating with > other projects as much as possible to get there.
What I see as the leading problem with all web application frameworks, including those distrbuted by Microsoft, Macromedia, and Sun, is the lack of realistic, best-practice applications that demonstrate why *each* and *every* feature is needed by the framework. I believe there should be a suite of applications that drive the development of the framework itself. If the application suite doesn't need it, then neither does the framework. By definition, frameworks are a means to an end. We should clearly define the end before creating the means. Another leading problem, as I see it, is that we keep building *web* application frameworks. IMHO, we should be building application frameworks first, and then exposing these applications to the web. By putting the focus first on the web, we end up putting way too much functionality into the web layer, where it is hard to reuse with other presentation systems. (Like, say, unit tests!) If our MVC mojo was up to snuff, it should not be so hard to write a MailReader application and then expose it on the web to Shale, Struts Classic, Ti, Spring MVC, Web Works, Tapestry, and so forth. We seem to be encouraging people to write applications *with* presentation frameworks, rather than *into* presentation frameworks. After putting it off way too long, I'm finally reading "Writing Effective Use Cases" by Cockburn (co-burn). We've started to use his "fully dressed" Use Cases" at work, and it's really putting things together for us. I've posted an example here: * http://husted.wush.net/docs/display/NEO/Log+Facility+Issue But Cockburn's Use Cases aren't just for users, developers can use them for the nuts-and-bolts too. Here's another example that I boldly borrowed straight from the book, used by an actual programming team. * http://husted.wush.net/docs/display/NEO/Serialize+Access+to+a+Resource My own itch is to start creating and maintaining web application frameworks in the same way that we create and maintain our own applications. (Or, at least the way we would create and maintain applications, if the PHBs let us do things right!) But, not to save the world or corner the market. But, because life is too short to use application frameworks that aren't being written by writing applications. What I'd like to do next with OverDrive is step back and write fully-dressed Use Cases for the framework's feature set. If a feature can't be justifed by a Use Case *and* demonstrated by a framework application, then out it goes :) So, I guess what I'm saying is that we might consider analyzing our own requirements for the framework that we want to use, in the same way we analyze the requirements of the applications our users want to use. Of course, not in a waterfall way, but at least in an Agile way. -- HTH, Ted. http://www.husted.com/poe/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
