Bugs item #1154077, was opened at 2005-03-01 01:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684975&aid=1154077&group_id=119783
Category: core
Group: 1.0
Status: Open
Resolution: None
Priority: 7
Submitted By: Jonathan Locke (jonathanlocke)
Assigned to: Eelco Hillenius (eelco12)
Summary: file upload package work
Initial Comment:
we need to finish this package, addressing the concerns
below in jonathan's email and we need to add features
for specifying a maximum upload size and a memory
threshold (although we're probably less interested in
the latter). in particular, it's key that upload have
a simple model that can be validated with the usual
wicket validators.
----
just took a look and made a couple trivial changes...
you really boiled it down nicely! i think we're real
close...
now that we've got this really basic thing that works,
i think we need to look at the model, which feels
funny. the reason i say that is that FileItem is an
implementation detail of the upload package in some
sense and probably should not escape that package. i'm
not sure what the model should be precisely, or if
there even should be one. the thing about models is
that they are user beans. if there is a model, it
should be a File object or maybe a String. something
that the user might be working with in their domain.
and there's nothing that even says a component /has/ to
have a model. the model could be null if it was
irrelevant.
one possible way to hide FileItem would be to have
FileInput expose a protected method
getDestinationFile(), which would allow the subclass to
determine where the file should be written, but not how
(since that's an implementation detail involved in
FileItem). another, i think better, possibility is
that the model of the FileInput (now FileUploadField)
should be a File object. that would make some sense
because the user ultimately wants a File object. the
only trick is that the user is responsible for
providing a File object that doesn't conflict with any
other uploads. which i think is fine. so
updateModel() would actually write the upload to the
File in the model. item.write((File)getModelObject()).
since File is the only possible Serializable object
for the second constructor, this:
public FileUploadField(String name, Serializable object)
would change to this:
public FileUploadField(String name, File file)
and UploadForm would change to FileUploadForm (because
a file is all that a user can upload in the end).
then there's the problem of FileItem.getInputStream().
we could expose this via a getInputStream() method on
FileUploadField. in that case, the user would not
supply a File model and updateModel() would not upload
the file since the user would call getInputStream().
finally, if we put this code:
final MultipartWebRequest multipartWebRequest =
((MultipartWebRequest)getRequest());
final FileItem item =
multipartWebRequest.getFile(getPath());
in a private method, getFileItem(), we could create a
FileUploadField.getInput() overload that would return
getFileItem().getName() (if the FileItem is not null).
this would help if the form doesn't validate, for one
thing, but it would also allow RequiredValidator or
PatternValidator to work with the component.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684975&aid=1154077&group_id=119783
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
