Jeff Brekke wrote:
> *) There is a dependency on jsdk2.2 in there that is busting the build with
> the older jsdk
>
> src/org/apache/turbine/services/resources/TurbineResources.java:501: Method
> getContextPath() not found in interface
> javax.servlet.http.HttpServletRequest.
> url.append(req.getContextPath());
Oops... Could please someone who uses JServ (I believe this is the only Servlets
2.0 container used aroud here) figure out, how to reconstruct an URL that
was used to access the servlet? I could also use some help in wraping it up
with reflection stuff.
> *) Unless there is some additional functionality in FileHandler/ORielly's
> uploaders, maybe we should just remove them and go with this default.
>
> or
>
> Merge any functionality into the TurbineUploader
>
> or
>
> Change the implementation slightly in FileHandler/OReilly to behave correctly
> ( populating the file list in the parameters, filenaming, memory cacheing )
> and set the uploader class to use in the TR.properties.
>
> It is confusing ( especially to the new user ) to have three uploaders, one
> which is the default with one behavior, another with a different behavior,
> etc. I'm not seeing any realy benefit to the multiple implementations in this
> area ( file uploading ).
There are three implemetnations, all share the same configuration mechanism:
services.TurbineResourceService.classname - implementating class
services.TurbineResourceService.repository - path for storing files (can be overriden
by Action)
services.TurbineResourceService.size.max - maximum size of requests to accept
(Action can enforce more strict limits)
services.TurbineResourceService.automatic - should ParameterParser pick up files
uncoditionally
the three implementation differ in what they do with uploaded files.
* TurbineUploadService makes files avaialbe from the ParameterParser as FileItems.
* OReillyUploadService puts them in the repository (or other custom directory) under
original names, then a vector of
filenames can be retrieved.
* FileHandlerUploadService puts the files in the repository under modified names, and
setst parameters
'_filehandler_filename' and '_filehandler_saved_filename' in the parameter parser.
The first implementation is the default and is intended to be used in the new code.
The other ones are available
to make old code usable with minimal or no modification.
We are still pre-release so dropping these code seems to be acceptable, but still I
think it keeping
it wouldn't really hurt anything. We could mark these implementation classes as
deprecated in Javadocs.
I'll check the code in as soon as JSDK 2.0 issue is resolved.
Rafal
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
