struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [PROPOSAL] Modular Struts Examples
Date Thu, 03 Jul 2003 17:15:12 GMT


On Wed, 2 Jul 2003, Vic Cekvenich wrote:

> Date: Wed, 02 Jul 2003 06:55:06 -0400
> From: Vic Cekvenich <vic_cekvenich@baseBeans.com>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message