Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
-- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25527927.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25615048.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
the problem is that trunk did not have version numbers updated so it was building as 1.4 for a while. this has been fixed so latest snapshots should be properly built out of branch. -igor On Sat, Sep 19, 2009 at 10:50 PM, Vladimir K koval...@gmail.com wrote: The latest 1.4 snapshot does not define IComponentBorder interface in addition to disappeared form component persistence. Is it supposed that 1.4.2 breaks compatibility with 1.4.1? I see the only way to check the fix in wicket-ajax.js - mix it into wicket 1.4.1 jar. Vladimir K wrote: I use 1.4-snapshot from http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ Persistence of form components has been removed from 1.4 as well.z martin-g wrote: You have to use 1.4.x branch. trunk is for 1.5. form persistence is removed only in trunk El vie, 18-09-2009 a las 05:32 -0700, Vladimir K escribió: Igor, thanks for the fix. I tried to compile against 1.4.2-20090916 and obtained two compilation errors. Now FormComponent does not contain method setPersistent() and Page does not contain method removePersistedFormData(). What API should be used instead? Vladimir K wrote: Igor, could you plan it for 1.4.2? Vladimir K wrote: done https://issues.apache.org/jira/browse/WICKET-2463 Vladimir K wrote: sure igor.vaynberg wrote: i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
The latest 1.4 snapshot does not define IComponentBorder interface in addition to disappeared form component persistence. Is it supposed that 1.4.2 breaks compatibility with 1.4.1? I see the only way to check the fix in wicket-ajax.js - mix it into wicket 1.4.1 jar. Vladimir K wrote: I use 1.4-snapshot from http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ Persistence of form components has been removed from 1.4 as well.z martin-g wrote: You have to use 1.4.x branch. trunk is for 1.5. form persistence is removed only in trunk El vie, 18-09-2009 a las 05:32 -0700, Vladimir K escribió: Igor, thanks for the fix. I tried to compile against 1.4.2-20090916 and obtained two compilation errors. Now FormComponent does not contain method setPersistent() and Page does not contain method removePersistedFormData(). What API should be used instead? Vladimir K wrote: Igor, could you plan it for 1.4.2? Vladimir K wrote: done https://issues.apache.org/jira/browse/WICKET-2463 Vladimir K wrote: sure igor.vaynberg wrote: i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25527927.html Sent from the Wicket - User mailing list
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
Igor, thanks for the fix. I tried to compile against 1.4.2-20090916 and obtained two compilation errors. Now FormComponent does not contain method setPersistent() and Page does not contain method removePersistedFormData(). What API should be used instead? Vladimir K wrote: Igor, could you plan it for 1.4.2? Vladimir K wrote: done https://issues.apache.org/jira/browse/WICKET-2463 Vladimir K wrote: sure igor.vaynberg wrote: i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25507890.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
You have to use 1.4.x branch. trunk is for 1.5. form persistence is removed only in trunk El vie, 18-09-2009 a las 05:32 -0700, Vladimir K escribió: Igor, thanks for the fix. I tried to compile against 1.4.2-20090916 and obtained two compilation errors. Now FormComponent does not contain method setPersistent() and Page does not contain method removePersistedFormData(). What API should be used instead? Vladimir K wrote: Igor, could you plan it for 1.4.2? Vladimir K wrote: done https://issues.apache.org/jira/browse/WICKET-2463 Vladimir K wrote: sure igor.vaynberg wrote: i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
I use 1.4-snapshot from http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ martin-g wrote: You have to use 1.4.x branch. trunk is for 1.5. form persistence is removed only in trunk El vie, 18-09-2009 a las 05:32 -0700, Vladimir K escribió: Igor, thanks for the fix. I tried to compile against 1.4.2-20090916 and obtained two compilation errors. Now FormComponent does not contain method setPersistent() and Page does not contain method removePersistedFormData(). What API should be used instead? Vladimir K wrote: Igor, could you plan it for 1.4.2? Vladimir K wrote: done https://issues.apache.org/jira/browse/WICKET-2463 Vladimir K wrote: sure igor.vaynberg wrote: i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25515394.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
Igor, could you plan it for 1.4.2? Vladimir K wrote: done https://issues.apache.org/jira/browse/WICKET-2463 Vladimir K wrote: sure igor.vaynberg wrote: i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25463838.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
done https://issues.apache.org/jira/browse/WICKET-2463 Vladimir K wrote: sure igor.vaynberg wrote: i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25397125.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
defaultFormProcessing is no longer considered when processing multipart form in ajax request
I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that?
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: defaultFormProcessing is no longer considered when processing multipart form in ajax request
sure igor.vaynberg wrote: i guess create a quickstart and attach it to a jira issue. when i tested buttons, while developing the feature, it seemed to work fine. -igor On Wed, Sep 9, 2009 at 10:40 PM, Vladimir K koval...@gmail.com wrote: it is attached to the input tag as follows: form wicket:id=actionForm enctype='multipart/form-data' div class=buttonBox input wicket:id=cancelAction type=submit wicket:message=value:command.cancelAction/input /div /form From my perspective the request is submitted very similar to as I remember submitting drop downs many years ago select onchange=this.form.submit(); The request parameters contain the name of the form instead of the name of the button. igor.vaynberg wrote: this bit of javascript: if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } is needed because we do perform a custom form serialization - really just constructing the query string - that we submit back to server via ajax. the multipart handling performs a regular post into a hidden iframe so the browser performs the serialization - and that should include the button. what markup is your button attached to? -igor On Wed, Sep 9, 2009 at 8:18 PM, Vladimir Kovalyuk koval...@gmail.com wrote: I added AjaxFallbackButton(Cancel).setDefaultFormProcessing(false) to the multipart form and when it is pressed the form is handled as well as the button would have defaultFormProcessing=true. It happens because request parameters does not contain the name of the submitting button. The magic is in the new code in wicket-ajax.js // Submits a form using ajax. // This method serializes a form and sends it as POST body. submitForm: function(form, submitButton) { if (this.handleMultipart(form)) { return true; } var body = function() { var s = Wicket.Form.serialize(form); if (submitButton != null) { s += Wicket.Form.encode(submitButton) + =1; } return s; } return this.request.post(body); }, I believe the problem is caused by handleMultipart(form) invocation. submitForm function accepts submitButton parameter but does not passes it to handleMultipart function. Igor could you clarify that? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377594.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/defaultFormProcessing-is-no-longer-considered-when-processing--multipart-form-in-ajax-request-tp25376538p25377634.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org