Date: 2005-03-06T04:53:48 Editor: DakotaJack Wiki: Apache Struts Wiki Page: StrutsUpload URL: http://wiki.apache.org/struts/StrutsUpload
no comment Change Log: ------------------------------------------------------------------------------ @@ -40,15 +40,15 @@ } }}} -The point of this presentation is not the classes given. The point is that I am would hope that the committers working on the Struts multipart processing would make some attempt to provide a basis for applications other than the Struts upload package. These classes are not meant to be that basis, other than the so-called "Framework Code" given below. If the code given so far is not sufficient to get a response other than the usual indifference, I will just go my own way. +The point of this presentation is not the classes given. The point is that I am would hope that the committers working on the Struts multipart processing would make some attempt to provide a basis for applications other than the Struts upload package. These classes are not meant to be that basis, other than the so-called "Framework Code" given below. -This is about Struts v1.2.6 and forward multipart requests. The first seven classes/interfaces are suggested as a basis for allowing Struts users/developers to implement their own file upload applications. The object of suggesting these classes is to make the use of !ActionForm available to users/developers who want to do something more than the present default file upload application packaged with Struts allows but maintaining backward compatibility. +This is about Struts v1.2.6 and forward multipart requests. The first four classes/interfaces are suggested as a basis for allowing Struts users/developers to implement their own file upload applications. The object of suggesting these classes is to make the use of !ActionForm available to users/developers who want to do something more than the present default file upload application packaged with Struts allows but maintaining backward compatibility. I assume that those committers working on the upload package can see how these classes could be seemlessly applied to Struts without disturbing expectations of prior users. -These classes, I believe, with minor revisions to the Struts framework allow this. If these classes seem remotely acceptable to those who decide such things, I will go on to code suggested changes to the framework, which really are not much. +The last three classes following the four main classes are example implementations of the first three interfaces and the !MultipartUtil. Any comments or suggestions are welcomed. -The last three of these seven classes are example implementations of the first three interfaces and the !MultipartUtil. Any comments or suggestions are welcomed. +After the seven classes a few classes to indicate what sorts of applications/implementations the seven classes would make possible are provided. All the classes following the first four classes are not meant to be part of the framework. If the example class Upload is studied, you will see that this class is totally ignorant of the view or the data coming from the multipart form. This is good. You will also see that, if the first four classes were part of the framework, the Upload class would also be totally ignorant of the request. This would be idea. As things stand, since non-Struts upload applications have no access to the !ActionForm, the Upload application has to have some hook to the framework to get the data for the view. This is what ideally we would like to avoid. -After the seven classes a few classes to indicate what sorts of applications/implementations the seven classes would make possible are provided. These latter classes are not meant to be part of the package but separate and only instructive, not part of the framework, but just consistent with and the sort of thing the framework should support, in my view. +I do use this application and others like it, but the point here is to see the flexibility that classes like the first four classes can give us. The important classes, the first three, are interfaces with "eXtremely" (pun intended) generic methods. Please note how easy the Upload class is to use. By having the flexibility to do what we need in the setup classes, the facade, the Upload class, is a piece of cake for the developer. === Framework Code === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
