On Wed, 27 Oct 2004 16:34:51 -0400, "Ted Husted" <[EMAIL PROTECTED]> wrote:
>> Instead of taking the approach of predicting what >> developers might want from Struts and JSF in the >> future > You probably have little to worry about in this > regard, Scott. :) Really? I am glad to hear that Shale will be efficiently solving all my future web application development problems. I can now rest easy. :) > Few, if any of us, are doing this for fun or profit. I would recommend that you try doing stuff for fun and profit. It has worked for me. > We do Struts, and would do Shale, because we want > to use the frameworks in our applications. Which, I > imagine, are much like yours :) If your applications are like mine then why are you not thinking of how you can be more productive in building your apps via the sharing of and collaborating on reusable application components, in addition to leveraging the very slim framework currently known as Struts. > For the most part, the development of Struts and > Shale is driven by what we need to do in our own > applications. Are these applications innovative? Can this innovation be shared? My suggestion of a reference application for Shale that also served as an authoring tool for applications running on the framework was motivated in part by hopes for it becoming a proving ground for innovative approaches that could be adopted and built upon. > But, do keep in mind that we are all working > developers here. Most of us are already writing > applications full-time (at least I am), and then > working on the framework at night :) The basis of this proposal was to suggest an efficient and productive approach to get wherever you (and hopefully most everyone else) want to go. If the investment in a 1st class reference application and reusable common application components is proven an inefficient use of resources then I would like to understand why. I firmly believe taking the approach of identifying what type of application meets the needs of the Struts developer community, identifying what kinds of tools would be useful for this development process, develop a production release of the sample application along with tools that demonstrated enhanced productivity, and *then* culling off reusable components as the framework layer could be a successful and efficient process. > Incidentally, the idea behind the Struts SourceForge > site was to host "community" applications. Perhaps > this will be a chance to get back to doing that > again. What is currently lacking from the original vision for this repository? > The application you mention at the end of your post > seems ambitious, but some "Starter Kits" would be a > very good idea. Our friends at ASP.NET offer several. My thought was that it should be ambitious in scope to demonstrate a complete solution that could easily be simplified during the developer's repurposing of the reference application. My thinking is related to my observations of how Eclipse and Netbeans are becoming reference applications in addition to their primary function of being IDEs. The tool I alluded to does not have to be a full blown IDE from its inception. Its first iteration could be a web application or service that spit out a WAR that could be used to assemble a slide show application. If that first step were taken by leveraging a portion of the Netbeans code base that is sitting in your web app's /WEB-INF/lib/ directory, then you have some confidence in succeeding with the evolving of this simple app to whatever a hosted browser-based IDE UI should look and behave like. Scott __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
