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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
