Date: 2005-03-01T21:57:51
Editor: DakotaJack
Wiki: Apache Struts Wiki
Page: StrutsUpload
URL: http://wiki.apache.org/struts/StrutsUpload
no comment
Change Log:
------------------------------------------------------------------------------
@@ -1,4 +1,8 @@
##language:en
+== Introduction ==
+
+I have tried to discuss ways to make life easy for everyone in the Struts
upload area, i.e. for the default application and for alternative applications.
As things stand, the default application is fairly wedded deep into the
framework itself, which, I think, is unnecessary and which, I think, stifles
chances to explore other options. There is nothing wrong, of course, with the
Struts upload application and this is not a criticism. I would, myself, like
to be able to use the ActionForm with a more "detailed" or more "sophisticated"
application. If we can get by that hurdle, I would be happy to donate the code
to Struts, if anyone wants it. Getting by that hurdle is not made easier by my
apparent difficulties communicating what I am trying to do to the committers.
They seem to think I am asking someone else to do something. I am not.
Anyway, if anyone has time to read all the following, that would be best. If
someone does not have the time, let me say that I am beginning by suggesting a
different approach to the present MultipartRequestHandler and
MultipartRequestWrapper, as well as to where wrapper and handler classes are
introduced into the framework. I have tried to build a wrapper (facade) and a
handler which will be agnostic towards any particular solutions, unlike the
present wrapper and handler. The wrapper/facade is not sufficient to pass to
the Action as the request. It is not even a wrapper in that sense. Nor, I
think, would that be desireable. However, if one wants to do that, I will
provide a true wrapper connected to the code by implementing the facade methods
in a wrapper in addition to the regular HttpServletRequest and ServletRequest
methods. On to the code, then. Any questions would be welcome: [EMAIL
PROTECTED]
+
== Struts Multipart Processing in Struts v1.2.6 for Upload Applications ==
The present code in Struts v1.2.6 and before is tied to the "default" or
"existing" upload application supplied in the Struts jar file. By "tied" I
mean that the code is coupled to that application such that it unnecessarily
impedes the development of competing or alternative implementations. This is
not a criticism of the default application. Rather, it is a desire to decouple
a particular implementation which is not a very sophisticated upload
application, from the framework. This is not a hard thing to do, and hopefully
this wiki page will start a discussion of how that might be achieved, if
desireable. As things stand, people regularly have to build around the
multipart processing in Struts rather than benefit from it. What is proposed
here hopefully would provide a basis for keeping what is good about the present
application while allowing other alternatives to be used too.
@@ -368,7 +372,7 @@
ufiFactory.setMonitors(monitors);
ufiFactory.setCustom(req.getContentLength());
- CommonsDiskFileUpload cdfu = new CommonsDiskFileUpload();
+ DiskFileUpload cdfu = new DiskFileUpload();
cdfu.setFileItemFactory(ufiFactory);
cdfu.setSizeMax(maxFileSize);
@@ -383,14 +387,14 @@
try {
list = cdfu.parseRequest(req);
- } catch(CommonsFileUploadException cfue) {
+ } catch(FileUploadException cfue) {
throw new IOException(cfue.getMessage());
}
Object obj = null;
for(Iterator iterator = list.iterator(); iterator.hasNext();) {
- CommonsFileItem cfi = (CommonsFileItem)iterator.next();
+ FileItem cfi = (FileItem)iterator.next();
String fieldName = cfi.getFieldName();
if(cfi.isFormField()) {
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
