Menu
▾
▴
RE: [Springframework-developer] Multipart File Handling
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-28 14:25:29
|
The conversion interface might indeed not be the perfect solution. A =
byte[] check is fine and fits the needs perfectly!
Alef
-----Oorspronkelijk bericht-----
Van: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]=20
Verzonden: Sunday, September 28, 2003 4:20 PM
Aan: al...@jt...; Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling
Alef,
=20
I'm not keen on introducing yet another converter interface, especially =
as there's hardly any variation possible in terms of file upload =
handling. I agree though that having MultipartFile in the object model =
isn't desirable.
=20
What about writing the automatic check in ServletRequestDataBinder so =
that it assumes a byte[] for the uploaded file? I can't think of any =
other generic type suitable for uploaded files. java.io.File is no =
candidate as we would need to determine a path to save the file to. I =
consider such persisting the responsibility of the application code =
itself, especially as the uploaded stuff will often be stored to a =
relational database.
=20
For anything else than byte[] as property type in a command object, even =
MultipartFile if desired, one can always override onBindAndValidate and =
perform manual binding. Would that be powerful enough for your use =
cases?
=20
Juergen
=20
=20
-----Urspr=C3=BCngliche Nachricht-----=20
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Gesendet: So 28.09.2003 15:31=20
An: j=C3=BCrgen h=C3=B6ller [werk3AT]; 'Trevor Cook'; 'Spring =
Developers'=20
Cc:=20
Betreff: RE: [Springframework-developer] Multipart File Handling
=09
=09
In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
=09
I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
=09
Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
=09
class FileUploadConvertor {
public Object convert(MultiPartFile);
}
=09
Just some thoughts...
=09
Alef
=09
=09
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Sunday, September 28, 2003 2:31 PM
Aan: al...@jt...; Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling
=09
=09
Hi Alef,
=09
A PropertyEditor will always start with a String and convert it to some =
other type, in the web case applied to ServletRequest's getParameter =
values. Here we got MultipartFile instances, retrievable via =
MultipartServletRequest's getFile(String name) method: no Strings in the =
first place, thus the PropertyEditor mechanism is not applicable.
=09
We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
=09
Definitely a feature worth considering!
=09
Juergen
=09
=09
=09
-----Urspr=C3=BCngliche Nachricht-----
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
Gesendet: So 28.09.2003 14:04
An: j=C3=BCrgen h=C3=B6ller [werk3AT]; 'Trevor Cook'; 'Spring =
Developers'
Cc:
Betreff: RE: [Springframework-developer] Multipart File =
Handling
=20
=20
=09
Will there be a way - using this solution - to bind the file =
using a propertyeditor (or something else maybe), just as any other =
command object is filled with parameters from the request. For =
consistency, I think that's pretty important to be consistent.
=20
Furthermore I think it's pretty cool if the fileupload could be =
fixed before the 1.0 release! Good thing!
=20
Alef
=20
=20
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Sunday, September 28, 2003 12:33 PM
Aan: Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File =
Handling
=20
=20
Hi Trevor,
=20
A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
=20
BTW, in contrast to COS, Commons FileUpload doesn't provide a =
Servlet 2.3 filter anyway. This means that there would be some =
infrastructure code to write for that use case too, even when using =
standard filters. A simple but convenient Spring solution would =
definitely be a good thing.
=20
Juergen
=20
=20
=20
=20
-----Urspr=C3=BCngliche Nachricht-----
Von: Trevor Cook [mailto:pr...@se...]
Gesendet: Sa 27.09.2003 19:35
An: Spring Developers
Cc:
Betreff: [[W3-SPAM]] - [Springframework-developer] =
Multipart File Handling - Email found in subject
=20
=20
=20
First some history:
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
=
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
7
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
=20
To address a few things Juergen mentioned previously.
=20
>> a less intrusive way would be to wrap the =
HttpServletRequest via a filter
I personally don't like the filter approach, at least =
for the framework. It
requires additional setup for the user (in the web.xml =
file) and might be
less understandable since our normal strategy so far =
has been with resolvers
inside the servlet.
=20
>>we would need to find concrete requirements for this
We have numerous uses for file upload handling. We =
have a public photo
contest where users can upload fotos. We have special =
access for suppliers
to upload product files (csv) which we then add in to =
our ordering system.
Finally, we have a web administration interface which =
allows our client to
upload files to the website so they can be downloaded. =
I think that
including this support (multipart handling) is a =
no-brainer.
=20
Basically, I have used COS exclusively in our projects, =
but I don't think
that's easy for Spring to use (due to the licensing). =
I would simply code
this according to Spring norms using an interface and a =
default version
using Commons FileUpload. Later, if somebody wants to =
create a cos version
we can (but to be honest, if we have a working, =
integrated solution I'm not
sure that is necessary - at least not in the Spring =
framework). Basically,
provide hooks and a default implementation, and allow =
users to adopt as
necessary.
=20
In our project we had modified the AbstractController =
and put the code into
it to handle the multipart processing, returning a =
wrapped
HttpServletRequest through the handlers. This is very =
similiar to Juergen's
outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
=20
Since we are migrating to the current Spring codebase, =
I need to move our
multipart handling code. The main question is whether =
we keep it
internally, or place it into Spring. I propose =
modifying
org.springframework.web.servlet.DispatcherServlet to =
have a
"MultipartResolver". In the DispatcherServlet, the =
resolver would be called
to wrap the request in doService immediately before =
getHandler(request) -
currently line 351, and then called to do any cleanup =
immediately before
exiting the doService method.
=20
I have about 2/3 of the code already written, and I =
will be writing the rest
between now and Monday. Does this strategy sound =
appropriate for Spring
(meaning should I commit it to the Spring codebase) =
when it's finished?
=20
Trevor D. Cook
Interprise Software
=20
=20
=20
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
=
https://lists.sourceforge.net/lists/listinfo/springframework-developer
=20
=20
N=18 Xu)=19Y g =17 HzGJ jg=EE=A2=B9z=ED=BD=89=ED=B7=99x=CB=A6 =
G =CB=B2q z m?X (=1E~zw X b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
=20
=20
=09
N=18 =E9=9A=8AX'u=DE=BC)=19 Y\g=E9=A2=AD =17 =7F b=D8=9EH=1EzG(=1FJ =
jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97x%R=CB=A6 (G^=EC=AE=BDh lq zm=D8=B6?X =
(=1E~zw X b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
=09
=09
|
