Re: Shale - Itch Proposal
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]
Shale - Itch Proposal
Instead of taking the approach of predicting what developers might want from Struts and JSF in the future and providing a few potentially unrealistic and overly simplistic demos, how about identifying a complete evolutionary or revolutionary sample web application and/or web service that would be truly useful to the Struts community. This application, along with the process of developing it, could be leveraged to shape what extensions to JSF and what complementary components from Struts would be worth investing in, while also serving to demonstrate proper design patterns and best practices. In my mind this would not be another Java Pet Store application, but a tool that would be used and leveraged to expose this evolved platform and/or development model to developers with little or no investment on their part. It looks to me like Struts will be focusing on describing application control and integration while JSF will be focusing on the presentation layer. At least this is how I am planning to leverage the two. It is my belief that successful web applications will need to become more customizable, personalizable, *and* more usable while these application's infrastructure become simplified from the perspective of both the developer and the consumer of the application. Integration requirements, in addition to those related to usability, led me to conclude that an iterative divide and conquer approach using standardized portlets held some promise. With this in mind, my proposal for a useful and demonstrative application would be the result of porting/supporting NetBeans' web application development APIs and relevant visual components to a JSR 168 portlet suite built on Struts components and JSF extensions. This suite would form the basis for a hosted IDE and project manager and could also leverage the Web Services for Remote Portlets (WSRP) OASIS standard to provide for project aggregation. I can see this authoring tool/portal being used to generate more focused tools and applications, a WAR factory, that in turn gets used by higher level developers and applied to more specific problem domains. I think this group can pull off something like this. 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]
Re: Shale - Itch Proposal
One example use that I am doing based on the Struts-Chain example: SoA access (via Hessian and a chain dispatcher) to Apache JackRabit CMS. W SoA, you can call from any API (Tiles, Portlet, JSTL, JSP, Servlet... any Java. or non Java, like C++). It's just a call that happens to dispatch and execute remotely. I may open source, I may not. I am quite disapointed that people are silent on JSF direction other than the 2 people who did not try it. .V Scott Anderson wrote: Instead of taking the approach of predicting what developers might want from Struts and JSF in the future and providing a few potentially unrealistic and overly simplistic demos, how about identifying a complete evolutionary or revolutionary sample web application and/or web service that would be truly useful to the Struts community. This application, along with the process of developing it, could be leveraged to shape what extensions to JSF and what complementary components from Struts would be worth investing in, while also serving to demonstrate proper design patterns and best practices. In my mind this would not be another Java Pet Store application, but a tool that would be used and leveraged to expose this evolved platform and/or development model to developers with little or no investment on their part. It looks to me like Struts will be focusing on describing application control and integration while JSF will be focusing on the presentation layer. At least this is how I am planning to leverage the two. It is my belief that successful web applications will need to become more customizable, personalizable, *and* more usable while these application's infrastructure become simplified from the perspective of both the developer and the consumer of the application. Integration requirements, in addition to those related to usability, led me to conclude that an iterative divide and conquer approach using standardized portlets held some promise. With this in mind, my proposal for a useful and demonstrative application would be the result of porting/supporting NetBeans' web application development APIs and relevant visual components to a JSR 168 portlet suite built on Struts components and JSF extensions. This suite would form the basis for a hosted IDE and project manager and could also leverage the Web Services for Remote Portlets (WSRP) OASIS standard to provide for project aggregation. I can see this authoring tool/portal being used to generate more focused tools and applications, a WAR factory, that in turn gets used by higher level developers and applied to more specific problem domains. I think this group can pull off something like this. 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]
Re: Shale - Itch Proposal
On Wed, 27 Oct 2004 12:01:39 -0700 (PDT), Scott Anderson [EMAIL PROTECTED] wrote: [snip] With this in mind, my proposal for a useful and demonstrative application would be the result of porting/supporting NetBeans' web application development APIs and relevant visual components to a JSR 168 portlet suite built on Struts components and JSF extensions. This suite would form the basis for a hosted IDE and project manager and could also leverage the Web Services for Remote Portlets (WSRP) OASIS standard to provide for project aggregation. I can see this authoring tool/portal being used to generate more focused tools and applications, a WAR factory, that in turn gets used by higher level developers and applied to more specific problem domains. I think this group can pull off something like this. I suspect you're probably correct about capabilities (building an IDE is my day job :-), but building an IDE seems a little aggressive to be a reasonable scope for a demonstration of the use of an application framework. That being said, I wholeheartedly endorse the idea of sample apps (more than one) -- that's the only way to validate whether the theoretical promises of easier development really come true or not. There are a bunch of different scenarios (webapp versus portlet, or database versus web service consumer, for example) that need to be examined, and deserve focused attention. I'd be happy to see such demos either in the Struts repository (for demos involving existing Struts committers) and at the Struts SourceForge project for those who just want to try things out and play. Personally, I'm going to start with our old friend MailReader -- not so much because it's a sophisticated demo, but as a simple entry point for people already familiar with the existing Struts implementation to see how the programming model might change, and also because I'm going to front end it with a system integration test to validate the functionality of the framework as it evolves. More complex scenarios, of course, are also needed -- volunteers are welcome. Scott Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
