This is a topic I continually return to, so I thought I would make a one time statement of my rough thoughts on these matters to both lists and save space in the long run.
I deal with applications. An upload application is a good starting point, because what I would like to be able to do with Struts is exemplified well by such an application. I like the Struts setup, but my requirements are not built to Struts but independent of Struts. For an upload application, the following is not only what I require but what I have done and do with Struts, albeit without being able to use the ActionForm, because the default upload architecture makes that more difficult than not. An interface Upload to the UploadAction in Struts which will provide the following "abilities", "services", etc. 1. Methods to dynamically add and remove monitors to the parsing process with the variables as hooks to the Upload implementations. Methods to access the state of these monitors. This has involved wrapping and overriding the parsing process in DiskFileUpload and FileItem in the commons fileupload package. 2. Methods with helper class parameters accessing the monitors, e.g. provide feedback on uploads, email upload state, etc. 3. Methods to set, to reset and to get stores in various types, e.g. directory, zip, memory, database, etc. storage, including coarse grained aspects such as getting connections to different databases, etc. 4. Methods to set and to get various file overwriting strategies. 5. Methods to dynamically set the parser. 6. Methods to control dynamically what extension types are uploaded either by "blacklist" or "whitelist" or otherwise relating to users, to applications, etc. 7. Methods to dynamical control the number and size of file uploads relating to users, to applications, etc. 8. Methods to dynamical set and get upload histories. So, essentially I want the Struts architecture to be able to accommodate facade classes relating to the model. To be able to work with the Struts architecture, the process of "massaging" the request provided to the Action and the process of adding data to the ActionForm I need an architecture to accommodate the various ways I might implement the Upload class and like classes for other applications. This means that ActionForm cannot, for example, restrict us to some FormFile class in RequestUtils, etc. This also means that the RequestProcessor process has to allow us to substitute in request wrappers, parsers, and handlers. The general idea should be clear. When choices are made, the interfaces should allow for options. Hope this is helpful. If not, please understand it was meant to be helpful. Jack -- "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]
