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
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
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
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.
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)...
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
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
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 at apache?
The
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
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
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
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
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
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
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
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. Other
+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 kind
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 this
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
19 matches
Mail list logo
