struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <dakota.j...@gmail.com>
Subject Re: Here's a question for yous...
Date Tue, 01 Mar 2005 06:57:45 GMT
Actually the RequestProcessor logic is irrelevant, although seemingly
not so.  You just need to alter RequestUtils.

My experience is that there are lots, and lots, of people doing
uploads in Struts outside the "norm".

I for one find tht the "ad nauseum" comments you refer to are as good
as gold as a rule.  You can always find silly coding, of course.  That
is rather the norm.  But, if you find good coding, then especially in
this multipart area, the results are wonderful in my experience. 
Doing multiparts by simply feeding the ActionForm back to the Action
is not really a good way to go in my opinion.  I have done a lot of
these "ad nauseum" things in upload and am just tickled pink about the
results.  I wish I could access ActionForm and will keep trying to get
that flexibility in.  It could be there in Struts v.1.2.6 without
causing any trouble so far as I see.


On Tue, 01 Mar 2005 00:52:07 -0500, Frank W. Zammetti
<fzlists@omnytex.com> wrote:
> Craig McClanahan wrote:
> > In Struts 1.0 - 1.2, there's no way to do this other than by
> > overriding RequestProcessor and dinking with the processPopulate()
> > method.  With the way 1.3 is evolving, it would be feasible to make
> > the Command that normally does population do something different
> > instead.
> 
> That was indeed one of my possible solutions.  However, what I'm doing
> doesn't warrant such effort, not by a long-shot.
> 
> > I can see where you're coming from, but I sure wonder how many people
> > are going to be surprised by this behavior that is so different from
> > the Struts norm.
> 
> Fair point.  I actually wound up just returning an ArrayList as a
> request attribute with the info I wanted to display.  That's really all
> I needed, but I've gotten away from ever passing data back to the view
> this way, hence my original question.  There were of course other
> options that would have gotten an ActionForm there, but in the end I
> figured KISS was the way to go.
> 
> > BTW, when upload gets integrated into Shale (I keep hearing Martin
> > talk about some upgrades to Commons FileUpload that I'd sure like to
> > see happen first :-), my thinking is that simple properties would
> > still be populated normally, but properties representing uploaded
> > files would get populated with an implementation of some adapter API
> > that bridges the difference between files that got cached in memory,
> > stored on disk, or whatever.  That way, the only behavior that is
> > different is that for the file upload field(s) -- everything else
> > continues to work as it does in a non-file-upload scenario.
> 
> I sometimes wonder if we (the generic we I mean) don't sometimes think
> at too high a level... We try to build so much flexibility into our
> designs, but every time I hear "a new API" or "a new interface" or
> "another abstraction layer" or any of those somewhat similar terms (you
> know, the ones spewed forth by enterprise architects ad nauseum!), I
> wonder if the cost of the added flexibility isn't too high in terms of
> overall complexity.
> 
> Eh, just a personal musing of mine.  Your plan as stated sounds pretty
> good :)
> 
> > Craig
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message