handleMultiPart() has been made protected non-final
-igor
On 1/19/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Just making sure it didn't get lost in some sourceforge tracker. Thx
for submitting!
Martijn
On 1/18/07, beboris <[EMAIL PROTECTED]> wrote:
>
> Yes, it is. I am sorry. I guess I
Just making sure it didn't get lost in some sourceforge tracker. Thx
for submitting!
Martijn
On 1/18/07, beboris <[EMAIL PROTECTED]> wrote:
>
> Yes, it is. I am sorry. I guess I confused some "transaction" ID with an
> issue ID...
>
>
> Eelco Hillenius wrote:
> >
> > It's this http://issues.apach
Yes, it is. I am sorry. I guess I confused some "transaction" ID with an
issue ID...
Eelco Hillenius wrote:
>
> It's this http://issues.apache.org/jira/browse/WICKET-220
>
> Eelco
>
>
> On 1/18/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>> Where did you create this issue?
>>
>> in Jira
It's this http://issues.apache.org/jira/browse/WICKET-220
Eelco
On 1/18/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> Where did you create this issue?
>
> in Jira at apache?
>
> The issue id doesn't seem to fit the profile.
>
> For the core projects (found at the download site at
> http://sf
Where did you create this issue?
in Jira at apache?
The issue id doesn't seem to fit the profile.
For the core projects (found at the download site at
http://sf.net/projects/wicket) we exclusively use JIRA at apache.
Martijn
On 1/18/07, beboris <[EMAIL PROTECTED]> wrote:
>
> Done (issue ID=123
Done (issue ID=12360795)
Eelco Hillenius wrote:
>
> If you could open up a feature request for that Boris, we can put it
> in the next version.
>
> Eelco
>
>> Also, please let me know what your plans for making method
>> "protected" are (starting with which version)...
>
> --
If you could open up a feature request for that Boris, we can put it
in the next version.
Eelco
> Also, please let me know what your plans for making method
> "protected" are (starting with which version)...
-
Take Surveys.
I tried overriding newWebRequest() [and defining our custom
MultipartWebRequest] on the application level and it seems to work for us.
Also, I extracted the base StreamUploadField class (which doesn't rely on
File-s being the result of the upload) from FileUploadField and used that
extracted class
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
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
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 CustomWebReques
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 th
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 met
> 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
Yeah, I got that. And they also likely break the contract of
WebRequest#newMultipartWebRequest, as they probably won't honor
calling that. Boris mentioned he wasn't happy about the
file-centric-ness of the current API, and I was wondering whether he
has suggestions to improve that.
Eelco
On 1/16
what i meant is that if someone overrides handlemultipart() on the form,
unless they do what we do they will break fileuploadfields
-igor
On 1/16/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> +1, however we do need to consider how this will effect the contract
with
> fileuploadfield. if th
> +1, however we do need to consider how this will effect the contract with
> fileuploadfield. if this is overridden then you can no longer count on the
> fileuploadfield's model to be properly populated and since the form is the
> intermediary it may not be obvious as to why.
Yeah. Boris, you kin
On 1/16/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> And, if not, may be the respected members of the wicket team
could consider simply making that method
> private final boolean handleMultiPart()
> "protected" and not "private final" in the next version...
That sounds fine by me: +1
> Anybody here knows if wicket can be extended to process Multi-part HTTP POST
> streams in a custom way?
It can, though not very obvious. Look at
wicket.extensions.ajax.markup.html.form.upload.UploadWebRequest, which
is a custom WebRequest. That works for the case where you want all of
your mu
Hi,
In short:
We are trying to do our own type of processing for Multi-part HTTP POST streams
and are sort of stuck with one of those beautiful "final" methods wicket
framework has in so many places.
More specifically:
We'd like to use Wicket Form for file uploads (with Ajax progress etc.). We
20 matches
Mail list logo