Re: getInputAsArray behavior
Actually this issue is reproducible in our project with select2 field
MultiSelect from here:
https://github.com/wicketstuff/core/tree/master/select2-parent
Will try to test using select2 example projects
On Mon, Feb 5, 2018 at 1:56 PM, Sven Meier wrote:
> Hi Maxim,
>
> are you using multipart requests? If not, there shouldn't be any change in
> serializing the input fields.
>
> I've tried Ajax and non-Ajax requests but cannot reproduce the problem.
> Are you entering "[null] into a field, without quotes but *with* square
> brackets?
>
> Sven
>
>
>
> Am 05.02.2018 um 03:28 schrieb Maxim Solodovnik:
>
>> Hello Sven,
>>
>> The issue is caused by this [1] commit
>> the form is now being serialized differently
>>
>> Previously FormComponent.getInputAsArray method got (Object)null as input
>> Right now it is [null] as List
>>
>> [1]
>> https://github.com/apache/wicket/commit/f642f4ad4266319731b2
>> 00e517eadf53fef5a56b
>>
>> On Mon, Feb 5, 2018 at 12:02 AM, Sven Meier wrote:
>>
>> Hi,
>>>
>>> Investigation shows "[null]" string is being converted to ["null"] (new
>>>
String[]{"null"}) by FormComponent.getInputAsArray method
"null" does not seem right. Can you pin down this problem to a recent
>>> commit in Wicket? I don't remember any change in FormComponent related to
>>> this.
>>>
>>> Regards
>>> Sven
>>>
>>>
>>>
>>> Am 04.02.2018 um 17:09 schrieb Maxim Solodovnik:
>>>
>>> Hello All,
'master' branch of our main application is based on 8.0.0-SNAPSHOT
Tonight we have error report: our latest build fails without changes in
our
code
Investigation shows "[null]" string is being converted to ["null"] (new
String[]{"null"}) by FormComponent.getInputAsArray method
I see no tests for this method, and I believe "[null]" input should be
converted to [null] (new String[]{null})
Shall I fix it in Wicket code on in our code?
>>
>
--
WBR
Maxim aka solomax
Re: getInputAsArray behavior
Hi Maxim,
are you using multipart requests? If not, there shouldn't be any change
in serializing the input fields.
I've tried Ajax and non-Ajax requests but cannot reproduce the problem.
Are you entering "[null] into a field, without quotes but *with* square
brackets?
Sven
Am 05.02.2018 um 03:28 schrieb Maxim Solodovnik:
Hello Sven,
The issue is caused by this [1] commit
the form is now being serialized differently
Previously FormComponent.getInputAsArray method got (Object)null as input
Right now it is [null] as List
[1]
https://github.com/apache/wicket/commit/f642f4ad4266319731b200e517eadf53fef5a56b
On Mon, Feb 5, 2018 at 12:02 AM, Sven Meier wrote:
Hi,
Investigation shows "[null]" string is being converted to ["null"] (new
String[]{"null"}) by FormComponent.getInputAsArray method
"null" does not seem right. Can you pin down this problem to a recent
commit in Wicket? I don't remember any change in FormComponent related to
this.
Regards
Sven
Am 04.02.2018 um 17:09 schrieb Maxim Solodovnik:
Hello All,
'master' branch of our main application is based on 8.0.0-SNAPSHOT
Tonight we have error report: our latest build fails without changes in
our
code
Investigation shows "[null]" string is being converted to ["null"] (new
String[]{"null"}) by FormComponent.getInputAsArray method
I see no tests for this method, and I believe "[null]" input should be
converted to [null] (new String[]{null})
Shall I fix it in Wicket code on in our code?
Re: getInputAsArray behavior
Hello Sven,
The issue is caused by this [1] commit
the form is now being serialized differently
Previously FormComponent.getInputAsArray method got (Object)null as input
Right now it is [null] as List
[1]
https://github.com/apache/wicket/commit/f642f4ad4266319731b200e517eadf53fef5a56b
On Mon, Feb 5, 2018 at 12:02 AM, Sven Meier wrote:
> Hi,
>
> Investigation shows "[null]" string is being converted to ["null"] (new
>> String[]{"null"}) by FormComponent.getInputAsArray method
>>
>
> "null" does not seem right. Can you pin down this problem to a recent
> commit in Wicket? I don't remember any change in FormComponent related to
> this.
>
> Regards
> Sven
>
>
>
> Am 04.02.2018 um 17:09 schrieb Maxim Solodovnik:
>
>> Hello All,
>>
>> 'master' branch of our main application is based on 8.0.0-SNAPSHOT
>> Tonight we have error report: our latest build fails without changes in
>> our
>> code
>>
>> Investigation shows "[null]" string is being converted to ["null"] (new
>> String[]{"null"}) by FormComponent.getInputAsArray method
>>
>> I see no tests for this method, and I believe "[null]" input should be
>> converted to [null] (new String[]{null})
>>
>> Shall I fix it in Wicket code on in our code?
>>
>>
>>
>>
>
--
WBR
Maxim aka solomax
Re: getInputAsArray behavior
Hi,
Investigation shows "[null]" string is being converted to ["null"] (new
String[]{"null"}) by FormComponent.getInputAsArray method
"null" does not seem right. Can you pin down this problem to a recent commit in
Wicket? I don't remember any change in FormComponent related to this.
Regards
Sven
Am 04.02.2018 um 17:09 schrieb Maxim Solodovnik:
Hello All,
'master' branch of our main application is based on 8.0.0-SNAPSHOT
Tonight we have error report: our latest build fails without changes in our
code
Investigation shows "[null]" string is being converted to ["null"] (new
String[]{"null"}) by FormComponent.getInputAsArray method
I see no tests for this method, and I believe "[null]" input should be
converted to [null] (new String[]{null})
Shall I fix it in Wicket code on in our code?
getInputAsArray behavior
Hello All,
'master' branch of our main application is based on 8.0.0-SNAPSHOT
Tonight we have error report: our latest build fails without changes in our
code
Investigation shows "[null]" string is being converted to ["null"] (new
String[]{"null"}) by FormComponent.getInputAsArray method
I see no tests for this method, and I believe "[null]" input should be
converted to [null] (new String[]{null})
Shall I fix it in Wicket code on in our code?
--
WBR
Maxim aka solomax
Re: 8.0.0 blockers
Hello Kamil, be careful when using this feature in production as there is a race condition meaning it depends on network, browser and client thread count if it works or not. - Ursprüngliche Mail - > Von: "Kamil Paśko" > An: dev@wicket.apache.org > Gesendet: Samstag, 3. Februar 2018 21:31:43 > Betreff: Re: 8.0.0 blockers > +1 > > I could test this "deferred javascript" issue on real application > > >> I'm for a new release too. We have a lot of fixes to release also for 7.x >> branch. >> >> On Feb 3, 2018 11:50 AM, "Martin Grigorov" >> wrote: >> >>> On Feb 3, 2018 09:03, "Maxim Solodovnik" wrote: >>> >>> Thanks a lot Andrea! >>> >>> Not sure if I can do more for the site update :( >>> >>> @Martijn maybe you can provide text for the upcoming release? >>> >>> @All, I'm not real fan of it, but maybe it worth to release another "M"? >>> >>> >>> I think it would be better to release another M or RC because there were >>> some bigger changes lately. >>> >>> >>> >>> WBR, Maxim >>> (from mobile, sorry for the typos) >>> >>> >>> On Fri, Feb 2, 2018, 16:25 Andrea Del Bene wrote: >>> Hi, I've updated copyright year. You don't see 2018 post because it has a future date, but you can use flag future:true to show it. On Fri, Feb 2, 2018 at 4:23 AM, Maxim Solodovnik wrote: > Hello All, > > I have question regarding site generation. > > I have added following file: 2018/_posts/2018-02-12-wicket- > 8.0.0-released.md > But news for 2018 are not being generated > > Is there any debugger I can use? > Or maybe I miss something? > > Copyright year is also 2017 :( > > > On Fri, Feb 2, 2018 at 12:09 AM, Sven Meier wrote: > >> Hi Korbinian, >> >> no problem at all! >> >> With the new JavaScriptFilteredHeaderResponse we can continue to improve >> deferred loading, without having to change anything in Wicket's core Ajax >> handling. >> >> Sven >> >> >> >> Am 01.02.2018 um 17:39 schrieb Korbinian Bachl: >> >>> Im really sorry Sven but I broke your defer patch :/ >>> >>> see comment here: >>> https://issues.apache.org/jira/browse/WICKET-6498 >>> >>> A solution to it is provided :) >>> >>> >>> - Ursprüngliche Mail - >>> Von: "Sven Meier" An: dev@wicket.apache.org Gesendet: Donnerstag, 1. Februar 2018 14:15:11 Betreff: Re: 8.0.0 blockers Hi, Am I right thinking Wicket 1.5 will be discontinued and Wicket6 >>> will be moved to "security updates only" mode? Yes I think so. Sven Gesendet mit Blue Am 1. Feb. 2018, 14:00, um 14:00, Maxim Solodovnik < > solomax...@gmail.com schrieb: > Hello All, > > I have created wicket-8 branch in wicket-site repository. > I believe the main work should be done in 2018/_posts/ > 2018-02-12-wicket-8.0.0-released.md file (I optimistically >>> "guess" > release > date to be 2018-02-12 :)) > Weanwhile I'll update quickstart generator so it will work with > "archetype:generate" 3.0.0+ and snapshot builds > > Am I right thinking Wicket 1.5 will be discontinued and Wicket6 >>> will > be > moved to "security updates only" mode? > > On Wed, Jan 31, 2018 at 5:54 PM, Andrea Del Bene < > an.delb...@gmail.com> > wrote: > > Hi, >> I've updated Confluence page to elaborate an answer to "Not blocking > but > >> really important" TODOs for Wicket 8. The page is here >> >> https://cwiki.apache.org/confluence/display/WICKET/ToDo+ > before+GA+release. > >> Please consider to work directly on my comment >>> integrating/changing > the > >> content of my post. This should help to come out with a final version > of > >> our official announcement. >> >> Thank you. >> >> On Thu, Jan 18, 2018 at 9:10 PM, Andrea Del Bene >> > > >> wrote: >> >> Just seen it :-) >>> >>> >>> On 18/01/2018 20:21, Martin Grigorov wrote: >>> >>> https://dzone.com/articles/would-you-use-jsf-for-your-next-project This might be used for inspiration for possible questions. On Wed, Jan 17, 2018 at 5:52 PM, Andrea Del Bene >>> >> wrote: I've created a Confluence page to collect some ideas on the >>> non-technical >>> tasks we should accomplish before going to roll out Wicket 8. I've >> started > with some personal thoughts o
[GitHub] wicket pull request #264: WICKET-6526 check HTTP method for all form submiss...
GitHub user duesenklipper opened a pull request: https://github.com/apache/wicket/pull/264 WICKET-6526 check HTTP method for all form submissions this moves the HTTP method check from onFormSubmitted to onFormSubmitted(submitter) so that every form submission performs this check, instead of only non-ajax requests. also adds tests that verify this. You can merge this pull request into a Git repository by running: $ git pull https://github.com/duesenklipper/wicket wicket8/WICKET-6526-ajaxbutton-methodmismatch Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/264.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #264 commit a03ee37d17b2e07f3d74268a4d874ac92cf69925 Author: Carl-Eric Menzel Date: 2018-02-03T23:10:23Z WICKET-6526 check HTTP method for all form submissions this moves the HTTP method check from onFormSubmitted to onFormSubmitted(submitter) so that every form submission performs this check, instead of only non-ajax requests. also adds tests that verify this. ---
[GitHub] wicket pull request #263: WICKET-6526 check HTTP method for all form submiss...
GitHub user duesenklipper opened a pull request: https://github.com/apache/wicket/pull/263 WICKET-6526 check HTTP method for all form submissions this moves the HTTP method check from onFormSubmitted to onFormSubmitted(submitter) so that every form submission performs this check, instead of only non-ajax requests. also adds tests that verify this. You can merge this pull request into a Git repository by running: $ git pull https://github.com/duesenklipper/wicket wicket7/WICKET-6526-ajaxbutton-methodmismatch Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/263.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #263 commit f850e13b6767debf23fd0bc6208187daf0a5d481 Author: Carl-Eric Menzel Date: 2018-02-03T23:10:23Z WICKET-6526 check HTTP method for all form submissions this moves the HTTP method check from onFormSubmitted to onFormSubmitted(submitter) so that every form submission performs this check, instead of only non-ajax requests. also adds tests that verify this. ---
[GitHub] wicket pull request #262: WICKET-6526 check HTTP method for all form submiss...
GitHub user duesenklipper opened a pull request: https://github.com/apache/wicket/pull/262 WICKET-6526 check HTTP method for all form submissions this moves the HTTP method check from onFormSubmitted to onFormSubmitted(submitter) so that every form submission performs this check, instead of only non-ajax requests. also adds tests that verify this. You can merge this pull request into a Git repository by running: $ git pull https://github.com/duesenklipper/wicket wicket6/WICKET-6526-ajaxbutton-methodmismatch Alternatively you can review and apply these changes as the patch at: https://github.com/apache/wicket/pull/262.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #262 commit 83ff231a10bd079f569c75253c4917ef69dcb0b9 Author: Carl-Eric Menzel Date: 2018-02-03T23:10:23Z WICKET-6526 check HTTP method for all form submissions this moves the HTTP method check from onFormSubmitted to onFormSubmitted(submitter) so that every form submission performs this check, instead of only non-ajax requests. also adds tests that verify this. ---
