This was what I meant with: 'It can, though not very obvious. Look at
wicket.extensions.ajax.markup.html.form.upload.UploadWebRequest'.
Guess I wasn't clear enough. But as I also stated in that answer, I
would be fine with making that method protected non-final if no urgent
objection arise in this thread.
Eelco
On 1/17/07, beboris <[EMAIL PROTECTED]> wrote:
>
> So, I guess you suggest we do it on the application level by overriding
> newWebRequest() method inside the whole WebApplication, so it returns our
> custom WebRequest subclass globally, as follows:
>
> protected WebRequest newWebRequest(HttpServletRequest servletRequest) {
> return new CustomWebRequest(servletRequest);
> }
>
> Then our CustomWebRequest class would in turn override
> newMultipartWebRequest() method and do custom processing globally, as
> opposed to working on the specific Form level which we could achieve should
> our CustomForm's handleMultiPart() method be overridable. Is that correct?
>
> If yes - do you see it as a workaround for a "simple" case or a generic
> solution for anyone who needs custom behavior of multi-part HTTP POST-s from
> forms?
>
> -boris
>
>
> igor.vaynberg wrote:
> >
> > you can already substitute your own implementation of IMultipartWebRequest
> > globally. the ajax-upload-progressbar does it
> >
> > -igor
> >
> >
> > On 1/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >>
> >> > 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...
> >>
> >> In general this sounds good to me. It would be a great help to us if
> >> someone (you) could provide us with a patch to make this concrete.
> >> Without a patch, I'm afraid this would be on the bottom of our current
> >> priority list (though we can do the change in Form anyway).
> >>
> >> Eelco
> >>
> >> -------------------------------------------------------------------------
> >> 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
> >>
> >
> > -------------------------------------------------------------------------
> > 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
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Impossible-to-customize-multi-part-POST-s-from-Form-s-in-Wicket-due-to-%22final%22-methods-tf3025509.html#a8420808
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
