I am glad you are open to making the handleMultiPart() method "protected".
While we understand your concern about existing "contracts", the dangers of
giving user ability to override and control multi-part stream handling may well
be exaggerated - especially considering getRequest/setRequest methods are
already available in the RequestCycle class. And, yes, if the user overrides
handleMultiPart() method he will be on his own as far as the upload results are
concerned. Consider it the price of "freedom"... [See the note on
FileUploadField-s later...]
Let me first tell you what we do today and how that will change once we have
the "protected" handleMultiPart() method available to us. In our today's code
we are forced to use files, but even today we don't rely on getting info on
those files from the form fields. We use the following code in the onSubmit()
method of our Form subclass to get to the results of the upload:
final Request request = getRequest();
if (request instanceof IMultipartWebRequest) {
IMultipartWebRequest multiReq = (IMultipartWebRequest)request;
Map fileItems = multiReq.getFiles();
...
}
As you see, we don't use FileUploadField "contracts" and live happily
thereafter... (well, except we don't need those intermediary files to start
with...:) ).
In case handleMultiPart() method is made protected all we need to do is create
our own wrapper (similar to MultipartServletWebRequest used inside Form) like
this:
class CustomForm extends Form {
...
private final boolean handleMultiPart() {
if (multiPart) {
try {
final CustomMultipartServletWebRequest customMultipartWebRequest =
new
CustomMultipartServletWebRequest((HttpServletRequest)getRequest(),this.maxSize);
getRequestCycle().setRequest(customMultipartWebRequest);
}
...
}
Then we'd handle streams "our way" inside that CustomMultipartServletWebRequest
class...
class CustomMultipartServletWebRequest {
...
CustomMultipartServletWebRequest( HttpServletRequest request, Bytes maxSize)
{...}
...
}
An example of MultipartServletWebRequest class would be of help, but otherwise,
it would be our class with our own logic. And it will be our responsibility to
handle stream parts any way we see fit... That's the goal...
IMHO, linking FileUploadField-s (which we need to browse for the correct input
file in the browser) with the specific (FileUpload, File) implementation of the
results of the multi-part HTTP POST streams (created when the form is
submitted) is too strong (and limiting) for a "generic" [and the only
available!] contract for multi-part HTTP POST streams in a generic-purpose web
framework like wicket. So, I'd suggest either leaving things the way they are
(FileUploadField-s will return null for FileUpload when File upload is not
used) or eliminating those FileUpload-related methods (let the user get this
info from (IMultipartWebRequest)request instead), or creating an extra layer of
objects (StreamUploadField-s, which would be a super-class for
FileUploadField-s without FileUpload-related contract obligations). In the
latter case, you'd give users those needed generic components that "look and
feel" (and smell :) ) like files on the client side, but are free for
interpretation on the server side. Still, today's FileUploadField-s would be
there as subclasses (in all their full-contract "glory") for backward
compatibility...
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
