On Wed, 2 Jul 2003, Vic Cekvenich wrote:
> Date: Wed, 02 Jul 2003 06:55:06 -0400 > From: Vic Cekvenich <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Modular Struts Examples > > -0. > > Module was... is optional and confusing. I think delay this a point > after 1.2. > We definitely need examples of modules, and all of the other individual features. I am not a believer that "one big example app" is the right way to approach that -- the sheer scale of such a thing would be a barrier to entry. It's better in some cases (say, illustrating the different ways you can use some of the tags) to have single-page illustrations (like what we do in struts-exercise-taglib, but focused on, and documented as, being examples rather than pseudo-unit-tests). Also, there's no way that one could ever hope to illustrate *all* possible best practices in a single application anyway, because there are legitimate application-specific needs to choose between various alternatives at every design point. The fact that you choose one particular strategy for user authentication (say, to use SecurityFilter instead of container managed authentication) does not automatically make all other choices "bad" or even "not best" -- they are just "different". > I think struts-upload could be deprecated (along with bean and logic > tags). People can do file upload out of commons, or using Jason Hunter's > COS upload. etc. Upload is not a Struts core value and could go back to > commons. Have you been paying attention, Vic? The Struts file upload implementation uses commons-fileupload already :-). More seriously, though, file uploading functionality really has two parts: * The generic part that can be (and is) used in any web application framework, and/or stand alone (as is the case with commons-fileupload, which is used by Turbine and Tapestry as well as by Struts). * The part that integrates the generic library into your particular framework (for our purposes, that's things like the <html:file> tag that is Struts-specific, and not appropriate for the generic library). It's entirely reasonable to have adapters like this; every other framework will do the same. We did the right thing by factoring out the common part of fileupload and sharing it -- just like we did with validator. But it is silly to suggest that Struts should give up the custom integration part of that, simply because the fundamental logic is generic. > > I would like for 1.2 to ... (can someone set up a "wish list" wiki > please?) is repackage into 2 jars: Struts core, and other (taglibs), a > few patches and a quick release. Also maybe Mavenize Struts build. As Ted says, the Wiki is available for everyone to make their own proposals. So is the STRUTS-DEV list :-). In either case, though, specific proposals (with specific action plans) are generally more likely to have useful effects, rather than generic suggestions. And, don't forget, patches often speak louder than words :-) > > (after 1.2 consolidate actions and beans classes). > > .V > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
