i dont know if it is a "workaround", it is just how the api is designed
currently.
what i am interested in is if doing this will solve your problem?
i also think we should make handlemultipart protected with a javadoc warning
that overrides may break fileuploadfields
-igor
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
