Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.
Thanks Martin, This is good news. Looking forward to 6.24.0. Kind regards, Fabio On Fri, Jun 17, 2016 at 10:26 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi Fabio, > > I agree that the removal of the default message is not really needed. > It has been done with https://issues.apache.org/jira/browse/WICKET-5735. > > I've reverted this with https://issues.apache.org/jira/browse/WICKET-6181 > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, Jun 13, 2016 at 1:43 PM, Fabio Fioretti < > windom.macroso...@gmail.com > > wrote: > > > Hi all, > > Does anybody have any feedback on this? > > > > Many thanks, > > Fabio > > > > On Tue, May 31, 2016 at 12:46 PM, Fabio Fioretti < > > windom.macroso...@gmail.com> wrote: > > > > > Hi Martin, > > > > > > You are right, the form id was already there in 6.17.0, but the default > > > message was removed! That is what is breaking my app - I did not > realize > > it > > > because my custom message was the same as the default. > > > > > > Why was it removed? > > > > > > In 6.17.0: > > > final String defaultValue = "Upload must be less than " + getMaxSize(); > > > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY, > > > Model.ofMap(model), defaultValue) > > > > > > While in 6.23.0: > > > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY, > > > Model.ofMap(model)); > > > > > > Interestingly, the comment still says "Resource key should be > > > .uploadTooLarge to override default message". > > > > > > IMHO, forcing to have the root (!) form id in the property key makes it > > > impossible to create a reusable component for managing uploads, like an > > > UploadPanel with its own form and FileUploadField . In fact, as soon as > > you > > > place it in a hierarchy that includes an outer form, it will break your > > > app. The default value at least provided a safe fallback. > > > > > > What do you think? > > > > > > Many thanks, > > > Fabio > > > > > > > > > On Mon, May 30, 2016 at 4:31 PM, Martin Grigorov <mgrigo...@apache.org > > > > > wrote: > > > > > >> Hi, > > >> > > >> On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti < > > >> windom.macroso...@gmail.com> wrote: > > >> > > >> > Hi Martin, > > >> > > > >> > Is this the ticket you refer to? > > >> > https://issues.apache.org/jira/browse/WICKET-5190 > > >> > > >> > > >> Yes, this is the one! > > >> > > >> > > >> > > > >> > > > >> > It has an explanation on why onFileUploadException() is called on > the > > >> root > > >> > form that seems reasonable. > > >> > > > >> > In any case, if I don't specify the form id in the property key > > (leaving > > >> > just "uploadTooLarge") I get the following MissingResourceException > > when > > >> > FileUploadBase.SizeLimitExceededException is thrown: > > >> > > > >> > > >> According to Git history the id was there even in 6.17: > > >> > > >> > > > https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1423 > > >> > > >> The id is not in Wicket 7.x though! > > >> It has been removed with > > >> https://issues.apache.org/jira/browse/WICKET-5206 > > >> 3 years ago > > >> > > >> > > >> > > > >> > *java.util.MissingResourceException*: Unable to find property: > > >> > 'form1.uploadTooLarge' for component: border:border_body:form1 > > >> > [class=org.apache.wicket.markup.html.form.Form]. > > >> > Locale: null, style: null > > >> > > > >> > As you can see, I do have a border complicating things (not sure if > it > > >> > might play a role here) but it worked just fine in Wicket 6.17.0. In > > >> fact I > > >> > had to add the form id ("form0.uploadTooLarge") to make it work in > > >> 6.23.0, > > >> > but then I ran into this other issue that, when form0 is nested in >
Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.
Hi all, Does anybody have any feedback on this? Many thanks, Fabio On Tue, May 31, 2016 at 12:46 PM, Fabio Fioretti < windom.macroso...@gmail.com> wrote: > Hi Martin, > > You are right, the form id was already there in 6.17.0, but the default > message was removed! That is what is breaking my app - I did not realize it > because my custom message was the same as the default. > > Why was it removed? > > In 6.17.0: > final String defaultValue = "Upload must be less than " + getMaxSize(); > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY, > Model.ofMap(model), defaultValue) > > While in 6.23.0: > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY, > Model.ofMap(model)); > > Interestingly, the comment still says "Resource key should be > .uploadTooLarge to override default message". > > IMHO, forcing to have the root (!) form id in the property key makes it > impossible to create a reusable component for managing uploads, like an > UploadPanel with its own form and FileUploadField . In fact, as soon as you > place it in a hierarchy that includes an outer form, it will break your > app. The default value at least provided a safe fallback. > > What do you think? > > Many thanks, > Fabio > > > On Mon, May 30, 2016 at 4:31 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > >> Hi, >> >> On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti < >> windom.macroso...@gmail.com> wrote: >> >> > Hi Martin, >> > >> > Is this the ticket you refer to? >> > https://issues.apache.org/jira/browse/WICKET-5190 >> >> >> Yes, this is the one! >> >> >> > >> > >> > It has an explanation on why onFileUploadException() is called on the >> root >> > form that seems reasonable. >> > >> > In any case, if I don't specify the form id in the property key (leaving >> > just "uploadTooLarge") I get the following MissingResourceException when >> > FileUploadBase.SizeLimitExceededException is thrown: >> > >> >> According to Git history the id was there even in 6.17: >> >> https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1423 >> >> The id is not in Wicket 7.x though! >> It has been removed with >> https://issues.apache.org/jira/browse/WICKET-5206 >> 3 years ago >> >> >> > >> > *java.util.MissingResourceException*: Unable to find property: >> > 'form1.uploadTooLarge' for component: border:border_body:form1 >> > [class=org.apache.wicket.markup.html.form.Form]. >> > Locale: null, style: null >> > >> > As you can see, I do have a border complicating things (not sure if it >> > might play a role here) but it worked just fine in Wicket 6.17.0. In >> fact I >> > had to add the form id ("form0.uploadTooLarge") to make it work in >> 6.23.0, >> > but then I ran into this other issue that, when form0 is nested in >> > form1, Wicket looks up for "form1.uploadTooLarge" instead. >> > >> > I also noticed that there is a new fileMaxSize property in Form that >> wasn't >> > there in 6.17.0. Should I use that one instead of maxSize? It has no >> setter >> > though... >> > >> >> This is related to https://issues.apache.org/jira/browse/WICKET-5735 >> >> >> > >> > Any clarification would be much appreciated. >> > >> > Many thanks, >> > Fabio >> > >> > On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <mgrigo...@apache.org> >> > wrote: >> > >> > > Hi, >> > > >> > > I believe there is/was another ticket describing exactly your problem >> > but I >> > > cannot find it now. >> > > >> > > The form id in the property key is not really needed. >> > > You could use it to give Wicket a more specific message for particular >> > > component. >> > > You can remove it if this message should/could be used for any other >> Form >> > > in you application/package/page/panel (depending in which .properties >> > file >> > > you have it). >> > > >> > > Martin Grigorov >> > > Wicket Training and Consulting >> > > https://twitter.com/mtgrigorov >> > > >> > > On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti < >> > > windom.macroso...@gmail.com &
Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.
Hi Martin, You are right, the form id was already there in 6.17.0, but the default message was removed! That is what is breaking my app - I did not realize it because my custom message was the same as the default. Why was it removed? In 6.17.0: final String defaultValue = "Upload must be less than " + getMaxSize(); String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY, Model.ofMap(model), defaultValue) While in 6.23.0: String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY, Model.ofMap(model)); Interestingly, the comment still says "Resource key should be .uploadTooLarge to override default message". IMHO, forcing to have the root (!) form id in the property key makes it impossible to create a reusable component for managing uploads, like an UploadPanel with its own form and FileUploadField . In fact, as soon as you place it in a hierarchy that includes an outer form, it will break your app. The default value at least provided a safe fallback. What do you think? Many thanks, Fabio On Mon, May 30, 2016 at 4:31 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti < > windom.macroso...@gmail.com> wrote: > > > Hi Martin, > > > > Is this the ticket you refer to? > > https://issues.apache.org/jira/browse/WICKET-5190 > > > Yes, this is the one! > > > > > > > > It has an explanation on why onFileUploadException() is called on the > root > > form that seems reasonable. > > > > In any case, if I don't specify the form id in the property key (leaving > > just "uploadTooLarge") I get the following MissingResourceException when > > FileUploadBase.SizeLimitExceededException is thrown: > > > > According to Git history the id was there even in 6.17: > > https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1423 > > The id is not in Wicket 7.x though! > It has been removed with https://issues.apache.org/jira/browse/WICKET-5206 > 3 years ago > > > > > > *java.util.MissingResourceException*: Unable to find property: > > 'form1.uploadTooLarge' for component: border:border_body:form1 > > [class=org.apache.wicket.markup.html.form.Form]. > > Locale: null, style: null > > > > As you can see, I do have a border complicating things (not sure if it > > might play a role here) but it worked just fine in Wicket 6.17.0. In > fact I > > had to add the form id ("form0.uploadTooLarge") to make it work in > 6.23.0, > > but then I ran into this other issue that, when form0 is nested in > > form1, Wicket looks up for "form1.uploadTooLarge" instead. > > > > I also noticed that there is a new fileMaxSize property in Form that > wasn't > > there in 6.17.0. Should I use that one instead of maxSize? It has no > setter > > though... > > > > This is related to https://issues.apache.org/jira/browse/WICKET-5735 > > > > > > Any clarification would be much appreciated. > > > > Many thanks, > > Fabio > > > > On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <mgrigo...@apache.org> > > wrote: > > > > > Hi, > > > > > > I believe there is/was another ticket describing exactly your problem > > but I > > > cannot find it now. > > > > > > The form id in the property key is not really needed. > > > You could use it to give Wicket a more specific message for particular > > > component. > > > You can remove it if this message should/could be used for any other > Form > > > in you application/package/page/panel (depending in which .properties > > file > > > you have it). > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti < > > > windom.macroso...@gmail.com > > > > wrote: > > > > > > > Hello everybody, > > > > > > > > I recently migrated an application from Wicket 6.17.0 to 6.23.0 and > I'm > > > > experiencing the following problem. > > > > > > > > I have 2 nested forms. The inner one, form0, contains a > FileUploadField > > > > with an AjaxFormSubmitBehavior(form0, "change") attached to it, while > > the > > > > external one, form1, wraps form0. > > > > > > > > form1 > > > > |__ > > > > form0 > > > > |__ > >
Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.
As a side note: finalMaxSize does have a setter in Form, sorry for the oversight. However, setting finalMaxSize on form0 has no effect... Only the one on form1 (the outer form) is actually enforced, but then again, properties must be defined at that level. Thanks, Fabio On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti < windom.macroso...@gmail.com> wrote: > Hi Martin, > > Is this the ticket you refer to? > https://issues.apache.org/jira/browse/WICKET-5190 > > It has an explanation on why onFileUploadException() is called on the root > form that seems reasonable. > > In any case, if I don't specify the form id in the property key (leaving > just "uploadTooLarge") I get the following MissingResourceException when > FileUploadBase.SizeLimitExceededException is thrown: > > *java.util.MissingResourceException*: Unable to find property: > 'form1.uploadTooLarge' for component: border:border_body:form1 > [class=org.apache.wicket.markup.html.form.Form]. > Locale: null, style: null > > As you can see, I do have a border complicating things (not sure if it > might play a role here) but it worked just fine in Wicket 6.17.0. In fact I > had to add the form id ("form0.uploadTooLarge") to make it work in 6.23.0, > but then I ran into this other issue that, when form0 is nested in > form1, Wicket looks up for "form1.uploadTooLarge" instead. > > I also noticed that there is a new fileMaxSize property in Form that > wasn't there in 6.17.0. Should I use that one instead of maxSize? It has no > setter though... > > Any clarification would be much appreciated. > > Many thanks, > Fabio > > On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > >> Hi, >> >> I believe there is/was another ticket describing exactly your problem but >> I >> cannot find it now. >> >> The form id in the property key is not really needed. >> You could use it to give Wicket a more specific message for particular >> component. >> You can remove it if this message should/could be used for any other Form >> in you application/package/page/panel (depending in which .properties file >> you have it). >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti < >> windom.macroso...@gmail.com >> > wrote: >> >> > Hello everybody, >> > >> > I recently migrated an application from Wicket 6.17.0 to 6.23.0 and I'm >> > experiencing the following problem. >> > >> > I have 2 nested forms. The inner one, form0, contains a FileUploadField >> > with an AjaxFormSubmitBehavior(form0, "change") attached to it, while >> the >> > external one, form1, wraps form0. >> > >> > form1 >> > |__ >> > form0 >> > |__ >> >FileUploadField >> > >> > When the user selects a file and a file upload exception is thrown (e.g. >> > FileSizeLimitExceededException), I would expect form0's >> > onFileUploadException() method to be invoked. However, the one of form1 >> is >> > invoked instead... >> > >> > As a result, Wicket starts looking for a property named >> > "form1.uploadTooLarge" instead of "form0.uploadTooLarge", thus breaking >> my >> > app, which only defines the latter. >> > >> > Is this an intended behavior? >> > >> > Was it introduced by https://issues.apache.org/jira/browse/WICKET-5753? >> > >> > And, by the way, what is the rationale of having the form id in the >> > property key? >> > >> > Many thanks in advance, >> > Fabio >> > >> > >
Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.
Hi Martin, Is this the ticket you refer to? https://issues.apache.org/jira/browse/WICKET-5190 It has an explanation on why onFileUploadException() is called on the root form that seems reasonable. In any case, if I don't specify the form id in the property key (leaving just "uploadTooLarge") I get the following MissingResourceException when FileUploadBase.SizeLimitExceededException is thrown: *java.util.MissingResourceException*: Unable to find property: 'form1.uploadTooLarge' for component: border:border_body:form1 [class=org.apache.wicket.markup.html.form.Form]. Locale: null, style: null As you can see, I do have a border complicating things (not sure if it might play a role here) but it worked just fine in Wicket 6.17.0. In fact I had to add the form id ("form0.uploadTooLarge") to make it work in 6.23.0, but then I ran into this other issue that, when form0 is nested in form1, Wicket looks up for "form1.uploadTooLarge" instead. I also noticed that there is a new fileMaxSize property in Form that wasn't there in 6.17.0. Should I use that one instead of maxSize? It has no setter though... Any clarification would be much appreciated. Many thanks, Fabio On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > I believe there is/was another ticket describing exactly your problem but I > cannot find it now. > > The form id in the property key is not really needed. > You could use it to give Wicket a more specific message for particular > component. > You can remove it if this message should/could be used for any other Form > in you application/package/page/panel (depending in which .properties file > you have it). > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti < > windom.macroso...@gmail.com > > wrote: > > > Hello everybody, > > > > I recently migrated an application from Wicket 6.17.0 to 6.23.0 and I'm > > experiencing the following problem. > > > > I have 2 nested forms. The inner one, form0, contains a FileUploadField > > with an AjaxFormSubmitBehavior(form0, "change") attached to it, while the > > external one, form1, wraps form0. > > > > form1 > > |__ > > form0 > > |__ > >FileUploadField > > > > When the user selects a file and a file upload exception is thrown (e.g. > > FileSizeLimitExceededException), I would expect form0's > > onFileUploadException() method to be invoked. However, the one of form1 > is > > invoked instead... > > > > As a result, Wicket starts looking for a property named > > "form1.uploadTooLarge" instead of "form0.uploadTooLarge", thus breaking > my > > app, which only defines the latter. > > > > Is this an intended behavior? > > > > Was it introduced by https://issues.apache.org/jira/browse/WICKET-5753? > > > > And, by the way, what is the rationale of having the form id in the > > property key? > > > > Many thanks in advance, > > Fabio > > >
AjaxFormSubmitBehavior, FileUploadField and nested forms.
Hello everybody, I recently migrated an application from Wicket 6.17.0 to 6.23.0 and I'm experiencing the following problem. I have 2 nested forms. The inner one, form0, contains a FileUploadField with an AjaxFormSubmitBehavior(form0, "change") attached to it, while the external one, form1, wraps form0. form1 |__ form0 |__ FileUploadField When the user selects a file and a file upload exception is thrown (e.g. FileSizeLimitExceededException), I would expect form0's onFileUploadException() method to be invoked. However, the one of form1 is invoked instead... As a result, Wicket starts looking for a property named "form1.uploadTooLarge" instead of "form0.uploadTooLarge", thus breaking my app, which only defines the latter. Is this an intended behavior? Was it introduced by https://issues.apache.org/jira/browse/WICKET-5753? And, by the way, what is the rationale of having the form id in the property key? Many thanks in advance, Fabio
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
I confirm version 6.23.0 fixed the problem. Thank you for the great support! Kind regards, Fabio On Thu, Apr 28, 2016 at 12:02 PM, Fabio Fioretti < windom.macroso...@gmail.com> wrote: > Thanks Andrea, that would be excellent! > > Keep up the great work, > Fabio > > On Thu, Apr 28, 2016 at 11:52 AM, Andrea Del Bene <an.delb...@gmail.com> > wrote: > >> Thank you for the issue! I think we can make it for next release 6.23.0 >> which should come quite soon (at the moment we are voting to release Wicket >> 6.23.0). >> >> Andrea. >> >> >> On 28/04/2016 11:34, Fabio Fioretti wrote: >> >>> Done: https://github.com/wicketstuff/core/issues/490 >>> >>> Many thanks, >>> Fabio >>> >>> On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov < >>> martin.grigo...@gmail.com >>> >>>> wrote: >>>> Please file an issue at Wicketstuff GibHub. >>>> On Apr 28, 2016 10:31 AM, "Fabio Fioretti" <windom.macroso...@gmail.com >>>> > >>>> wrote: >>>> >>>> Hi Martin, >>>>> >>>>> Thanks, I agree - findOffices() shouldn't be executed at all. In fact, >>>>> handleMethodExecution() returns before invoking application code in all >>>>> other cases (step 1 for unauthorized access, step 3 for validation >>>>> >>>> errors). >>>> >>>>> Any chance to have it fixed relatively soon? (maybe Andrea can answer >>>>> >>>> this) >>>> >>>>> Kind regards, >>>>> Fabio >>>>> >>>>> On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov <mgrigo...@apache.org >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> >>>>>> On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < >>>>>> windom.macroso...@gmail.com> wrote: >>>>>> >>>>>> Hi all, >>>>>>> >>>>>>> Please consider the following simple implementation of >>>>>>> >>>>>> AbstractRestResource >>>>>> >>>>>>> (6.22.0): >>>>>>> >>>>>>> @ResourcePath("/rest/api") >>>>>>> public class MyRestResource extends >>>>>>> AbstractRestResource >>>>>>> { >>>>>>> >>>>>>> public MyRestResource () >>>>>>> { >>>>>>>super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); >>>>>>> } >>>>>>> >>>>>>> @MethodMapping(value = "/offices") >>>>>>> public List findOffices( >>>>>>> @RequestParam(value = "region", required = false) Integer >>>>>>> >>>>>> regionId) >>>> >>>>> { >>>>>>>return findOfficesByRegion(regionId); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> My question relates to the findOffices method and its filtering >>>>>>> >>>>>> regionId >>>>> >>>>>> parameter when the value is not a valid integer. For example, >>>>>>> >>>>>> consider >>>> >>>>> the >>>>>> >>>>>>> request 'GET /rest/api/offices?region=AA'. >>>>>>> >>>>>>> At the second step of AbstractRestResource.handleMethodExecution, >>>>>>> extractMethodParameters is invoked, which in turn triggers the >>>>>>> >>>>>> conversion >>>>> >>>>>> of all parameters through the static method toObject. >>>>>>> >>>>>>> When the conversion goes wrong and ConversionException is thrown, >>>>>>> >>>>>> toObject >>>>>> >>>>>>> catches it, sets the response status to 400 and returns null! >>>>>>> >>>>>>> Now, when my findOffices is finally executed, I get a null regionId >>>>>>> >>>>>> but I >>>>> >>>>>> don't know whether it was not valid or the parameter was not present >>>>>>> >>>>>> at >>>> >>>>> all. Checking the response status downstream is also particularly >>>>>>> >>>>>> hard >>>> >>>>> because I have no getStatus (Tomcat 6 here, ouch!). >>>>>>> >>>>>>> To my mind, findOffices should return null instead of the unfiltered >>>>>>> >>>>>> list >>>>> >>>>>> of offices if the conversion went wrong, even because the response >>>>>>> status is 400 (as set by toObject). However, how can I know it? >>>>>>> >>>>>>> Any suggestions? >>>>>>> >>>>>>> IMO this is a bug in the library. >>>>>> #findOffices() should not be executed at all. >>>>>> A response with status code 400 should be returned immediately after >>>>>> >>>>> the >>>> >>>>> unsuccessful convention without giving a chance to the application code >>>>>> >>>>> to >>>>> >>>>>> be executed. >>>>>> >>>>>> Many thanks, >>>>>>> Fabio >>>>>>> >>>>>>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Thanks Andrea, that would be excellent! Keep up the great work, Fabio On Thu, Apr 28, 2016 at 11:52 AM, Andrea Del Bene <an.delb...@gmail.com> wrote: > Thank you for the issue! I think we can make it for next release 6.23.0 > which should come quite soon (at the moment we are voting to release Wicket > 6.23.0). > > Andrea. > > > On 28/04/2016 11:34, Fabio Fioretti wrote: > >> Done: https://github.com/wicketstuff/core/issues/490 >> >> Many thanks, >> Fabio >> >> On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov < >> martin.grigo...@gmail.com >> >>> wrote: >>> Please file an issue at Wicketstuff GibHub. >>> On Apr 28, 2016 10:31 AM, "Fabio Fioretti" <windom.macroso...@gmail.com> >>> wrote: >>> >>> Hi Martin, >>>> >>>> Thanks, I agree - findOffices() shouldn't be executed at all. In fact, >>>> handleMethodExecution() returns before invoking application code in all >>>> other cases (step 1 for unauthorized access, step 3 for validation >>>> >>> errors). >>> >>>> Any chance to have it fixed relatively soon? (maybe Andrea can answer >>>> >>> this) >>> >>>> Kind regards, >>>> Fabio >>>> >>>> On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov <mgrigo...@apache.org> >>>> wrote: >>>> >>>> Hi, >>>>> >>>>> >>>>> On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < >>>>> windom.macroso...@gmail.com> wrote: >>>>> >>>>> Hi all, >>>>>> >>>>>> Please consider the following simple implementation of >>>>>> >>>>> AbstractRestResource >>>>> >>>>>> (6.22.0): >>>>>> >>>>>> @ResourcePath("/rest/api") >>>>>> public class MyRestResource extends >>>>>> AbstractRestResource >>>>>> { >>>>>> >>>>>> public MyRestResource () >>>>>> { >>>>>>super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); >>>>>> } >>>>>> >>>>>> @MethodMapping(value = "/offices") >>>>>> public List findOffices( >>>>>> @RequestParam(value = "region", required = false) Integer >>>>>> >>>>> regionId) >>> >>>> { >>>>>>return findOfficesByRegion(regionId); >>>>>> } >>>>>> } >>>>>> >>>>>> My question relates to the findOffices method and its filtering >>>>>> >>>>> regionId >>>> >>>>> parameter when the value is not a valid integer. For example, >>>>>> >>>>> consider >>> >>>> the >>>>> >>>>>> request 'GET /rest/api/offices?region=AA'. >>>>>> >>>>>> At the second step of AbstractRestResource.handleMethodExecution, >>>>>> extractMethodParameters is invoked, which in turn triggers the >>>>>> >>>>> conversion >>>> >>>>> of all parameters through the static method toObject. >>>>>> >>>>>> When the conversion goes wrong and ConversionException is thrown, >>>>>> >>>>> toObject >>>>> >>>>>> catches it, sets the response status to 400 and returns null! >>>>>> >>>>>> Now, when my findOffices is finally executed, I get a null regionId >>>>>> >>>>> but I >>>> >>>>> don't know whether it was not valid or the parameter was not present >>>>>> >>>>> at >>> >>>> all. Checking the response status downstream is also particularly >>>>>> >>>>> hard >>> >>>> because I have no getStatus (Tomcat 6 here, ouch!). >>>>>> >>>>>> To my mind, findOffices should return null instead of the unfiltered >>>>>> >>>>> list >>>> >>>>> of offices if the conversion went wrong, even because the response >>>>>> status is 400 (as set by toObject). However, how can I know it? >>>>>> >>>>>> Any suggestions? >>>>>> >>>>>> IMO this is a bug in the library. >>>>> #findOffices() should not be executed at all. >>>>> A response with status code 400 should be returned immediately after >>>>> >>>> the >>> >>>> unsuccessful convention without giving a chance to the application code >>>>> >>>> to >>>> >>>>> be executed. >>>>> >>>>> Many thanks, >>>>>> Fabio >>>>>> >>>>>> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Done: https://github.com/wicketstuff/core/issues/490 Many thanks, Fabio On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov <martin.grigo...@gmail.com > wrote: > Please file an issue at Wicketstuff GibHub. > On Apr 28, 2016 10:31 AM, "Fabio Fioretti" <windom.macroso...@gmail.com> > wrote: > > > Hi Martin, > > > > Thanks, I agree - findOffices() shouldn't be executed at all. In fact, > > handleMethodExecution() returns before invoking application code in all > > other cases (step 1 for unauthorized access, step 3 for validation > errors). > > > > Any chance to have it fixed relatively soon? (maybe Andrea can answer > this) > > > > Kind regards, > > Fabio > > > > On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov <mgrigo...@apache.org> > > wrote: > > > > > Hi, > > > > > > > > > On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < > > > windom.macroso...@gmail.com> wrote: > > > > > > > Hi all, > > > > > > > > Please consider the following simple implementation of > > > AbstractRestResource > > > > (6.22.0): > > > > > > > > @ResourcePath("/rest/api") > > > > public class MyRestResource extends > > > > AbstractRestResource > > > > { > > > > > > > > public MyRestResource () > > > > { > > > > super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); > > > > } > > > > > > > > @MethodMapping(value = "/offices") > > > > public List findOffices( > > > >@RequestParam(value = "region", required = false) Integer > regionId) > > > > { > > > > return findOfficesByRegion(regionId); > > > > } > > > > } > > > > > > > > My question relates to the findOffices method and its filtering > > regionId > > > > parameter when the value is not a valid integer. For example, > consider > > > the > > > > request 'GET /rest/api/offices?region=AA'. > > > > > > > > At the second step of AbstractRestResource.handleMethodExecution, > > > > extractMethodParameters is invoked, which in turn triggers the > > conversion > > > > of all parameters through the static method toObject. > > > > > > > > When the conversion goes wrong and ConversionException is thrown, > > > toObject > > > > catches it, sets the response status to 400 and returns null! > > > > > > > > Now, when my findOffices is finally executed, I get a null regionId > > but I > > > > don't know whether it was not valid or the parameter was not present > at > > > > all. Checking the response status downstream is also particularly > hard > > > > because I have no getStatus (Tomcat 6 here, ouch!). > > > > > > > > To my mind, findOffices should return null instead of the unfiltered > > list > > > > of offices if the conversion went wrong, even because the response > > > > status is 400 (as set by toObject). However, how can I know it? > > > > > > > > Any suggestions? > > > > > > > > > > IMO this is a bug in the library. > > > #findOffices() should not be executed at all. > > > A response with status code 400 should be returned immediately after > the > > > unsuccessful convention without giving a chance to the application code > > to > > > be executed. > > > > > > > > > > > Many thanks, > > > > Fabio > > > > > > > > > >
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Hi Martin, Thanks, I agree - findOffices() shouldn't be executed at all. In fact, handleMethodExecution() returns before invoking application code in all other cases (step 1 for unauthorized access, step 3 for validation errors). Any chance to have it fixed relatively soon? (maybe Andrea can answer this) Kind regards, Fabio On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > > On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < > windom.macroso...@gmail.com> wrote: > > > Hi all, > > > > Please consider the following simple implementation of > AbstractRestResource > > (6.22.0): > > > > @ResourcePath("/rest/api") > > public class MyRestResource extends > > AbstractRestResource > > { > > > > public MyRestResource () > > { > > super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); > > } > > > > @MethodMapping(value = "/offices") > > public List findOffices( > >@RequestParam(value = "region", required = false) Integer regionId) > > { > > return findOfficesByRegion(regionId); > > } > > } > > > > My question relates to the findOffices method and its filtering regionId > > parameter when the value is not a valid integer. For example, consider > the > > request 'GET /rest/api/offices?region=AA'. > > > > At the second step of AbstractRestResource.handleMethodExecution, > > extractMethodParameters is invoked, which in turn triggers the conversion > > of all parameters through the static method toObject. > > > > When the conversion goes wrong and ConversionException is thrown, > toObject > > catches it, sets the response status to 400 and returns null! > > > > Now, when my findOffices is finally executed, I get a null regionId but I > > don't know whether it was not valid or the parameter was not present at > > all. Checking the response status downstream is also particularly hard > > because I have no getStatus (Tomcat 6 here, ouch!). > > > > To my mind, findOffices should return null instead of the unfiltered list > > of offices if the conversion went wrong, even because the response > > status is 400 (as set by toObject). However, how can I know it? > > > > Any suggestions? > > > > IMO this is a bug in the library. > #findOffices() should not be executed at all. > A response with status code 400 should be returned immediately after the > unsuccessful convention without giving a chance to the application code to > be executed. > > > > > Many thanks, > > Fabio > > >
[wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Hi all, Please consider the following simple implementation of AbstractRestResource (6.22.0): @ResourcePath("/rest/api") public class MyRestResource extends AbstractRestResource { public MyRestResource () { super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); } @MethodMapping(value = "/offices") public List findOffices( @RequestParam(value = "region", required = false) Integer regionId) { return findOfficesByRegion(regionId); } } My question relates to the findOffices method and its filtering regionId parameter when the value is not a valid integer. For example, consider the request 'GET /rest/api/offices?region=AA'. At the second step of AbstractRestResource.handleMethodExecution, extractMethodParameters is invoked, which in turn triggers the conversion of all parameters through the static method toObject. When the conversion goes wrong and ConversionException is thrown, toObject catches it, sets the response status to 400 and returns null! Now, when my findOffices is finally executed, I get a null regionId but I don't know whether it was not valid or the parameter was not present at all. Checking the response status downstream is also particularly hard because I have no getStatus (Tomcat 6 here, ouch!). To my mind, findOffices should return null instead of the unfiltered list of offices if the conversion went wrong, even because the response status is 400 (as set by toObject). However, how can I know it? Any suggestions? Many thanks, Fabio
Re: [wicketstuff-restannotations] How to automatically generate Swagger definitions.
Hi Andrea, Thanks anyway. No big deal in doing it manually with the Swagger editor for me, but having some kind of built-in automation would be great for large APIs. By the way, I have another question more strictly related to restannotations, for which I am going to start another thread. Kind regards, Fabio On Tue, Apr 26, 2016 at 10:19 PM, Andrea Del Bene <an.delb...@gmail.com> wrote: > Hi, > > at the moment we don't have such kind of integration with Swagger. You may > obtain some results if you use Spring in your application: > https://dzone.com/articles/swagger-make-developers-love. > However I've never tried this kind of solution. > > > On 25/04/2016 16:08, Fabio Fioretti wrote: > >> Hi all, >> >> I have been successfully using wicketstuff-restannotations to create some >> REST web services in my Wicket 6.22.0 application - thanks for that, very >> straightforward. >> >> Now that my REST resources and methods are complete and correctly >> annotated, I would need to generate the related Swagger definitions. >> >> Is there an easy way to do so? >> >> Many thanks, >> Fabio >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
[wicketstuff-restannotations] How to automatically generate Swagger definitions.
Hi all, I have been successfully using wicketstuff-restannotations to create some REST web services in my Wicket 6.22.0 application - thanks for that, very straightforward. Now that my REST resources and methods are complete and correctly annotated, I would need to generate the related Swagger definitions. Is there an easy way to do so? Many thanks, Fabio
Re: Backward compatibility with URLs generated by HybridUrlCodingStrategy.
Many thanks Martin, I followed your advice and ended up overriding SystemMapper's mapRequest. I decided to simply strip away the page instance instead of moving it to the query string. It's just noise for me, after all. Quite rough probably, but it seems to do the job in all the cases I tried. Do you foresee any problem with this piece of code? I'm not really confident the way to identify the page instance is correct, and I'm afraid it could add too much overhead (note: isNumber is implemented using Character.isDigit, as suggested here: http://jdevelopment.nl/efficient-determine-string-number/). setRootRequestMapper(*new* SystemMapper(*this*) { @Override *public* IRequestHandler mapRequest(Request request) { *final* Url url = request.getUrl(); *final* String lastSegment = !url.getSegments().isEmpty() ? url.getSegments().get(url.getSegments().size() - 1) : *null*; *if* (lastSegment != *null* lastSegment.contains(.)) { *final* String presumedPageInstance = lastSegment.substring(lastSegment.lastIndexOf(.) + 1); *if* (isNumber(presumedPageInstance)) { // If it's a number, assume it's the page Id and strip it from the request URL. *final* String cleanedUpLastSegment = lastSegment.substring(0, lastSegment.lastIndexOf(.)); url.getSegments().set(url.getSegments().size() - 1, cleanedUpLastSegment); *return* *super*.mapRequest(request.cloneWithUrl(url)); } } *return* *super*.mapRequest(request); } }); Many thanks, Fabio On Wed, Jun 11, 2014 at 2:12 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Fabio, You can create your own root request mapper that when detecting an old url can either : 1) return a redirect with code 301 (Moved permanently) 2) just move the page id from the last segment to the query string silently Martin Grigorov Wicket Training and Consulting On Wed, Jun 11, 2014 at 1:00 PM, Fabio Fioretti windom.macroso...@gmail.com wrote: Hi all, I am migrating an application from Wicket 1.4 to 6.15. This app makes use of HybridUrlCodingStrategy, that I replaced with a MountedMapped using UrlPathPageParametersEncoder. The problem is that many users have old bookmarks of URLs generated by HybridUrlCodingStrategy, in which the page instance number comes after a dot, like in the following example: http://myapp.com/mount/path/param/value.4 Now, with MountedMapper and UrlPathPageParametersEncoder, the same URL looks like this (mind the ? replacing the .): http://myapp.com/mount/path/param/value?4 The result is that the old dotted bookmarks do not work anymore (HTTP 404). Any suggestion on the best approach to guarantee backward compatibility with old URLs? Thanks very much in advance, Fabio Fioretti
Re: Backward compatibility with URLs generated by HybridUrlCodingStrategy.
Hi Martin, Thanks for your time and help. Even though my 1.4 URLs contain pageIds, in the moment they were bookmarked they were basically made stateless to my application, as the pageId lost meaning. It is now just noise that gets misinterpreted by the migrated app because of the dotted notation. All I wanted to achieve is to make them work in Wicket 6.x and, to do that, it is sufficient to strip the bookmarked pageId away and let Wicket reassign a new one with the proper encoding (? instead of .). Kind regards, Fabio On Thu, Jun 12, 2014 at 2:54 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Fabio, The code looks OK! Indeed it is not very easy to create really bookmarkable url! The page has to be stateless to have url that will produce the same result every time. With stateful pages (pages with pageId in their url) there is a chance to load something different than what you expect ... but all this is known. You can search the mail archives for NoVersionRequestMapper to workaround this. But it will lead to different kind of problems. Martin Grigorov Wicket Training and Consulting On Thu, Jun 12, 2014 at 2:19 PM, Fabio Fioretti windom.macroso...@gmail.com wrote: Many thanks Martin, I followed your advice and ended up overriding SystemMapper's mapRequest. I decided to simply strip away the page instance instead of moving it to the query string. It's just noise for me, after all. Quite rough probably, but it seems to do the job in all the cases I tried. Do you foresee any problem with this piece of code? I'm not really confident the way to identify the page instance is correct, and I'm afraid it could add too much overhead (note: isNumber is implemented using Character.isDigit, as suggested here: http://jdevelopment.nl/efficient-determine-string-number/). setRootRequestMapper(*new* SystemMapper(*this*) { @Override *public* IRequestHandler mapRequest(Request request) { *final* Url url = request.getUrl(); *final* String lastSegment = !url.getSegments().isEmpty() ? url.getSegments().get(url.getSegments().size() - 1) : *null*; *if* (lastSegment != *null* lastSegment.contains(.)) { *final* String presumedPageInstance = lastSegment.substring(lastSegment.lastIndexOf(.) + 1); *if* (isNumber(presumedPageInstance)) { // If it's a number, assume it's the page Id and strip it from the request URL. *final* String cleanedUpLastSegment = lastSegment.substring(0, lastSegment.lastIndexOf(.)); url.getSegments().set(url.getSegments().size() - 1, cleanedUpLastSegment); *return* *super*.mapRequest(request.cloneWithUrl(url)); } } *return* *super*.mapRequest(request); } }); Many thanks, Fabio On Wed, Jun 11, 2014 at 2:12 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Fabio, You can create your own root request mapper that when detecting an old url can either : 1) return a redirect with code 301 (Moved permanently) 2) just move the page id from the last segment to the query string silently Martin Grigorov Wicket Training and Consulting On Wed, Jun 11, 2014 at 1:00 PM, Fabio Fioretti windom.macroso...@gmail.com wrote: Hi all, I am migrating an application from Wicket 1.4 to 6.15. This app makes use of HybridUrlCodingStrategy, that I replaced with a MountedMapped using UrlPathPageParametersEncoder. The problem is that many users have old bookmarks of URLs generated by HybridUrlCodingStrategy, in which the page instance number comes after a dot, like in the following example: http://myapp.com/mount/path/param/value.4 Now, with MountedMapper and UrlPathPageParametersEncoder, the same URL looks like this (mind the ? replacing the .): http://myapp.com/mount/path/param/value?4 The result is that the old dotted bookmarks do not work anymore (HTTP 404). Any suggestion on the best approach to guarantee backward compatibility with old URLs? Thanks very much in advance, Fabio Fioretti
Backward compatibility with URLs generated by HybridUrlCodingStrategy.
Hi all, I am migrating an application from Wicket 1.4 to 6.15. This app makes use of HybridUrlCodingStrategy, that I replaced with a MountedMapped using UrlPathPageParametersEncoder. The problem is that many users have old bookmarks of URLs generated by HybridUrlCodingStrategy, in which the page instance number comes after a dot, like in the following example: http://myapp.com/mount/path/param/value.4 Now, with MountedMapper and UrlPathPageParametersEncoder, the same URL looks like this (mind the ? replacing the .): http://myapp.com/mount/path/param/value?4 The result is that the old dotted bookmarks do not work anymore (HTTP 404). Any suggestion on the best approach to guarantee backward compatibility with old URLs? Thanks very much in advance, Fabio Fioretti
CachingResourceStreamLocator is not extension-aware.
Hi all, I have a Wicket 6 application that integrates with Apache FOP in a way that, by overriding Page's getMarkupType(), I can have a component render its .fo markup (to generate a PDF) instead of the usual html, depending on whether it is added to a Page with the fo MarkupType or the standard html one. This means my typical Panel has two markup files, an html one and a fo one: Panel.fo and Panel.html. Now, the default CashingResourceStreamLocator makes use of ResourceReference#Key for the cache. That Key completely ignores the extension of the file or, better, assumes it is part of the name, while for markup files this is apparently not the case. Basically, Panel.html and Panel.fo have the same Key, the name of which is simply Panel. Therefore, when a Panel is first rendered in html, its html markup reference is cached and there is no way to make it render again in fo, because the cache will always return the html markup reference. The solution is not dramatic but makes me feel uncomfortable: I had to write a custom CashingResourceStreamLocator clone, using a custom Key that is basically a ResourceReference#Key with an added extension property. What am I missing here? Thanks very much for you help and keep up the excellent work, Fabio Fioretti
Re: CachingResourceStreamLocator is not extension-aware.
Hi Martin, I have just created a ticket: https://issues.apache.org/jira/browse/WICKET-5581 Thanks for taking it into consideration. Overriding #getVariation() works well but it is, as you say, a workaround. I look forward to having CachingResourceStreamLocator improved. Thanks again, Fabio On Tue, May 6, 2014 at 12:51 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, Please file a ticket at https://issues.apache.org/jira/browse/WICKET and we will improve it. As a workaround you can override #getVariation() for the pages and return html and fo respectively. Martin Grigorov Wicket Training and Consulting On Tue, May 6, 2014 at 11:39 AM, Fabio Fioretti windom.macroso...@gmail.com wrote: Hi all, I have a Wicket 6 application that integrates with Apache FOP in a way that, by overriding Page's getMarkupType(), I can have a component render its .fo markup (to generate a PDF) instead of the usual html, depending on whether it is added to a Page with the fo MarkupType or the standard html one. This means my typical Panel has two markup files, an html one and a fo one: Panel.fo and Panel.html. Now, the default CashingResourceStreamLocator makes use of ResourceReference#Key for the cache. That Key completely ignores the extension of the file or, better, assumes it is part of the name, while for markup files this is apparently not the case. Basically, Panel.html and Panel.fo have the same Key, the name of which is simply Panel. Therefore, when a Panel is first rendered in html, its html markup reference is cached and there is no way to make it render again in fo, because the cache will always return the html markup reference. The solution is not dramatic but makes me feel uncomfortable: I had to write a custom CashingResourceStreamLocator clone, using a custom Key that is basically a ResourceReference#Key with an added extension property. What am I missing here? Thanks very much for you help and keep up the excellent work, Fabio Fioretti
Re: wicket and ext-js
Hi Frank, Sorry for the late reply. We are currently migrating our main application from Wicket 1.3 to 1.4 and contextually upgrading ext-wicket. This might eventually be the right occasion to update the project, though we are still targetting Ext 2.2. With regard to behaviors and components, we felt it was useful to keep them separate in spite of a small overhead, as it is always easy to merge them but much more complicated to extract a behavior from a component. Anyway, ext-wicket was born to help up support Ext-JS components we found interesting for our applications, and not to provide a clean and complete mapping of Ext features into Wicket. Therefore, its architecture is far from perfect! Is your integration effort moving forward? Kind regards, Fabio On Wed, Sep 29, 2010 at 4:43 PM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: hi Fabio, good to hear it is in active use and development! There might be more users than you think; perhaps you can get them to voice their enthousiasm. Might help to find the time to publish the changes? Concerning your example, some behaviors are definitively offered best as actual wicket behaviors. Tooltips, data stores, other services you need from the client. But I still wonder whether that justifies the overhead, considering the large number of components. Are there other motivations like, I could imagine, needing to subclass the FormComponent to be able to participate in form processing? thanks, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket and ext-js
Hi, I am one of the developers behind wicket-ext. The project hasn't been updated lately even though it is still used, maintained and developed behind closed doors. We stopped updating it both because of lack of public interest (we have received only few external contributions) and because of the fact that the Ext-JS components we found most useful for our applications are already supported (i.e. we currently have no real interest in driving the endeavour further). In addition, we had no time to clean-up the latest code to the extent of releasing it publicly. I can say that the integration was quite straightforward and Wicket proved to work very well with Ext-JS; in particular, we found grid components (GridPanel, GroupingView, etc.) extremely useful. The separation of Behaviors and Components hierarchies was a design decision rooted in flexibility and actually inspired by Wicket: we wanted to allow the application of Ext behaviors to standard Wicket components. Just to give an example, think of a PersistentTip applied to a Wicket TextField through a simple textField.add(new ExtBaloonBehavior(model)). Why would you need a custom TextField for that? Good luck for your integration effort and, should you decide to build on top of wicket-ext, feel free to ask. Cheers, Fabio Fioretti On Wed, Sep 29, 2010 at 12:09 PM, Frank van Lankvelt f.vanlankv...@onehippo.com wrote: I'm in the process of integrating Ext-JS into our Wicket application. So there are a number of questions, such as: What are your experiences of using wicket and ext together? Do these projects help at all, or do you rather roll a custom behavior each time? Is there some project that is not indexed by Google (see below)? Are there some fundamental problems one runs into when building more complex UIs? I found two projects that provide an integration; - wicket-ext at http://code.google.com/p/wicket-ext/ - wicket-extjs-integration http://code.google.com/p/wicket-extjs-integration/ Neither of these is very active, but I'm hoping that some of you have experience with them. The wicket-ext project has lots of widgets already integrated, but I don't really understand the reason for creating two hierarchies; one of Components and one of Behaviors. It seems to me that mapping ext components onto wicket components should be sufficient; behaviors can then be added to provide services to the client-side code. The wicket-extjs-integration project is in its infancy, but has a lot of potential; it maps ext components directly onto wicket components, has been explicitly designed to do composition and even has a nice way of invoking ext client-side methods from server-side code. I also like the annotation-based configuration of the client-side components. I would like to continue work on the second approach, but would like to get some feeling for the task at hand first ;-) thanks, Frank -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [OT] Wicket changed my life !
Peter, I completely agree with you. :-) Thanks Wicket! Fabio On Fri, Feb 19, 2010 at 9:37 AM, Peter Ertl pe...@gmx.org wrote: Wicket put the suck out of web development for me :-) Am 19.02.2010 um 08:14 schrieb Josh Kamau: Me too!! On Fri, Feb 19, 2010 at 9:57 AM, Ashika Umanga Umagiliya auma...@biggjapan.com wrote: I love Wicket ! - 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: Switch tab only if user doesn't want to save changes.
On Wed, Mar 11, 2009 at 6:30 PM, jchappelle jchappe...@4redi.com wrote: Could you post how you are detecting unsaved changes? I am trying to implement something similar. Hi Josh, it depends on the kind of data you are dealing with, but basically it is just a matter of keeping the initial model object values somewhere and comparing them with the new ones resulting from form updating by the user. Regards, Fabio Fioretti - WindoM - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [OT] wicket users around the world
Rome, Italy! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Switch tab only if user doesn't want to save changes.
Thank you Maurice, what you suggested matched the way I was trying to solve the problem, but I had to add a bit of client-side logic to decide whether to display the confirm dialog or not, basing the decision on the enabled/disabled status of the save button inside the first tab, which already implemented the logic to detect unsaved changes. I paste the relevant bits to share my solution with you all. Probably it's not optimal at all, so please do feel free to comment/correct/laugh. :) @Override protected IAjaxCallDecorator getAjaxCallDecorator() { // Add custom decorator for tabs other than the one containing detailsPanel if ( index != 0 ) { return new AjaxCallDecorator() { @Override public CharSequence decorateScript( CharSequence script ) { // Ask for user confirmation, as tab-switching discards unsaved changes. final String saveButton = detailsPanel != null ? detailsPanel.getSaveButtonMarkupId() : ; final StringBuffer decoration = new StringBuffer(); return decoration.append(String.format(if( document.getElementById('%s')!= null , saveButton)) .append(String.format( !document.getElementById('%s').disabled , saveButton)) .append( !confirm('Please note that unsaved changes will be lost.\\n\\nDo you want to switch tab?')) ) .append({ return false; }) .append(script); } }; } return super.getAjaxCallDecorator(); } Cheers, Fabio Fioretti - WindoM On Sun, Jul 13, 2008 at 9:43 PM, Maurice Marrink [EMAIL PROTECTED] wrote: Override newLink to return an ajaxfallbacklink where you have overridden the getAjaxCallDecorator method to return a custom IAjaxCallDecorator. Use that to insert a javascript confirm dialog. Maurice On Fri, Jul 11, 2008 at 7:28 PM, Fabio Fioretti [EMAIL PROTECTED] wrote: Hi all, thanks in advance for your precious support. I have an AjaxTabbedPanel with two tabs. In the first tab there is a panel with a form, some input fields and a save button; the content of the second tab is irrelevant. Use-case: 1 - user selects first tab; 2 - user makes some changes in the input fields but doesn't click the save button; 3 - user selects second tab. On step 3, users loses all his updates without being warned. I would like to add a javascript confirm dialog to be triggered only when some changes have been performed but not saved (no ModalWindow, just javascript). I mean something like: There are some unsaved changes that will be lost, do you really want to switch tab? OK Cancel. OK brings the user to the second tab, Cancel makes him stay in the first tab. The panel inside the first tab has a handy boolean hasUnsavedChanges() method, but I don't know where I could call it and how to inject an if (!confirm('...')) return false;. Maybe in the onClick(AjaxRequestTarget target) method of the AjaxFallbackLink returned by AjaxTabbedPanel's newLink() method? What's the best way to do it? Thank you very much, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Switch tab only if user doesn't want to save changes.
Hi all, thanks in advance for your precious support. I have an AjaxTabbedPanel with two tabs. In the first tab there is a panel with a form, some input fields and a save button; the content of the second tab is irrelevant. Use-case: 1 - user selects first tab; 2 - user makes some changes in the input fields but doesn't click the save button; 3 - user selects second tab. On step 3, users loses all his updates without being warned. I would like to add a javascript confirm dialog to be triggered only when some changes have been performed but not saved (no ModalWindow, just javascript). I mean something like: There are some unsaved changes that will be lost, do you really want to switch tab? OK Cancel. OK brings the user to the second tab, Cancel makes him stay in the first tab. The panel inside the first tab has a handy boolean hasUnsavedChanges() method, but I don't know where I could call it and how to inject an if (!confirm('...')) return false;. Maybe in the onClick(AjaxRequestTarget target) method of the AjaxFallbackLink returned by AjaxTabbedPanel's newLink() method? What's the best way to do it? Thank you very much, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Wicket 1.3.3] Possible wicket:enclosure regression.
Hi All, I'm experiencing a possible regression for wicket:enclosure in Wicket 1.3.3 (maybe related to the couple of patches that involved enclosures for 1.3.3). It thought of a regression because the following code works just fine in 1.3.1, even if I haven't tested it in 1.3.2. Basically, I have a RadioGroup with a couple of options. When the user selects the second option, a text field and link (wrapped in an enclosure) should appear next to the option. If she/he selects the first option, they should disappear again. Their visibility management is based on the enclosure. wicket:extend form wicket:id=form span wicket:id=radioGroup input wicket:id=radioOne type=radio value=U span onclick=event.cancelBubble = true;Set OPTION ONE br/ /span input wicket:id=radioTwo type=radio value=P/ span onclick=event.cancelBubble = true;Set OPTION TWO wicket:enclosure child=textField input wicket:id=textField type=text/ a wicket:id=linklink/a /wicket:enclosure br/ /span /span input type=button wicket:id=submitButton/ /form /wicket:extend On the Java side, the relevant code looks like this (feel free to ask for further details): radioGroup.add(new AjaxFormRadioUpdatingBehavior(onclick){ @Override protected void onUpdate(AjaxRequestTarget target) { if (OPTION_ONE.equals(getSelectedOption())) { textField.setVisible(true); } else { textField.setVisible(false); } target.addComponent(radioGroup); } }); As you can see, I set the visibility of the textField depending on the selected option and then update the container (the radioGroup). Again, it worked fine in 1.3.1. Is anybody aware of this or has anyone else experienced the same change in enclosure functioning from Wicket 1.3.1 to 1.3.3? Thank you very much and keep up the good work! Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 1.4 with only generics and stop support for 1.3
+1. Best regards, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trigger ajax-form submit when changing tabs
If I understand your problem correctly, you could override the newLink() method of the AjaxTabbedPanel to return an AjaxSubmitLink instead. Something like the following: tabPanel = new AjaxTabbedPanel(tabs, tabs){ @Override protected WebMarkupContainer newLink(String linkId, final int index) { return new AjaxSubmitLink(linkId, yourForm) { @Override protected void onSubmit(AjaxRequestTarget target, Form form) { setSelectedTab(index); if (target != null) { target.addComponent(tabPanel); } onAjaxUpdate(target); } @Override protected void onError(AjaxRequestTarget target, Form form){ AjaxUtils.error(form); } }; } }; Disclaimer: the code above is based on Wicket 1.2.6. Cheers, Fabio Fioretti - WindoM On Jan 17, 2008 1:21 PM, Steffen Fritzsche [EMAIL PROTECTED] wrote: Hi, I have the following problem. I created a three individual forms each within its own Tab (implementing AbstractTab). Each is submitted via ajax according to the Ajax-FormPage example. All forms are backed by the same Model-Object representing a simple Product wrapped in a BoundCompoundPropertyModel. On the surrounding page I have a forth form just with a submit button. This form refers to the same Product-Object and when the button is clicked it performs some action cleans up my Product Object and persists it via JPA. This is working so far, but currently I have to hit my ajax-submit button always before switching between each of the three real forms using the tabs. Is there an elagant solution to trigger this ajax submit and validating the form elements of the currently active form when the user clicks on one of the other form-tabs. So that I do not need a visible ajax-submit button anymore ... Steffen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 14, 2008 1:35 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: Documenting Wicket's inner implementations and strategies, beyond its API, is desirable and a huge plus for hardcore developers. i wouldnt think hardcore developers would be afraid of setting a breakpoint and walking the code. maybe one of them could even create a wiki page - open source and all that. Yup. Please anyone, take the initiative and write a WIKI page. That's more constructive than complaining about it here :-) Good if it is done by someone outside anyway, because that someone won't make the assumptions we probably would make. We'll be happy to review. Fine, this can be a good compromise: documentation written by the skilled community and reviewed by the developers themselves. I'm not that hardcore now, but the more I get into Wicket, the more I'll try to help out as much as I can. Thanks, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 14, 2008 1:00 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: easy to say when its not you who has to put in the huge effort :) I'm just a humble junior developer. :) Regards, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 12, 2008 8:56 PM, Dmitry Kandalov [EMAIL PROTECTED] wrote: On the whole I think it's the matter of knowing the big picture and not using framework as a black box. Exactly. For knowledge's sake. Documenting Wicket's inner implementations and strategies, beyond its API, is desirable and a huge plus for hardcore developers. Sure, we could study the code, but it can lead to bad assumptions if it's not coupled with some sort of high-level, even gross-grained, documentation. So, +1 for Paolo, even if I understand that the documentation effort can become huge. Cheers, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Wicket 1.2.6] How to get Wizard's form from inside a WizardStep?
Thanks everybody for the precious help, a custom lazy AjaxFormSubmitBehavior was the way to go. Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Wicket 1.2.6] How to get Wizard's form from inside a WizardStep?
First of all, many compliments for the great Wicket 1.3 release: we're looking forward to port our application to the new cool version! How can I get the Wizard's form from inside a WizardStep? I need it to trigger an AjaxSubmitLink which should update a part of my model while remaining inside that step. What leaves me clueless is the fact that WizardStep instances are added to the WizardModel instead of the Wizard, so doing something like this from inside the WizardStep: Form form = (Form)WizardStep.this.findParent(Form.class); seems to return null; moreover, this makes me wonder how the same instruction inside WizardStep.AddFormValidatorAction.execute() can succeed. I'm sure I'm missing something really stupid. Please forgive me. :-) Thanks a lot, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep inserted data on AjaxTabbedPanel tab switching.
Hi, this is how I implemented it: tabPanel = new AjaxTabbedPanel(tabs, tabs){ @Override protected WebMarkupContainer newLink(String linkId, final int index) { return new AjaxSubmitLink(linkId, candidateForm) { private static final long serialVersionUID = 1L; @Override protected void onSubmit(AjaxRequestTarget target, Form form) { setSelectedTab(index); if (target != null) { target.addComponent(tabPanel); } onAjaxUpdate(target); } @Override protected void onError(AjaxRequestTarget target, Form form){ AjaxUtils.error(form); } }; } }; Kindest regards, Fabio Fioretti - WindoM On Nov 14, 2007 1:18 PM, lizz [EMAIL PROTECTED] wrote: Hi, I tried implementing the submitLink but dont really understand what I do wrong as I still loose the data. Could you provide me with your code in the newlink metthod please... I am new to web development so I might have forgotten some obvious stuff ... Thanks :-) Fabio Fioretti wrote: On 9/21/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you have to override newlink on the tabbedpanel and return a submitlink instead Nice, this worked just fine! also, really, for situations like this it doesnt make sense to use a server-side panel. use client side tabs like what jquery provides instead - it works much better with forms. I agree, but this is not the case: I simplified the situation to frame the question more easily, but it's more complex in reality. Thanks a lot for your precious help, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Keep-inserted-data-on-AjaxTabbedPanel-tab-switching.-tf4493055.html#a13745653 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird Ajax non-English characters encoding problem.
Hi Matej and Johan, thanks for your replies. I'm using Latin1 because the page I'm talking about is part of a legacy web application fully encoded in ISO-8859-1. The application server it runs on is Tomcat 5.5, which defaults to Latin1, so it shouldn't be a problem. I tried to set the request/response encoding in the application main class using: getRequestCycleSettings().setResponseRequestEncoding(ISO-8859-1); but nothing changed, except that Wicket Ajax Debug now prints: INFO: ?xml version=1.0 encoding=ISO-8859-1?ajax-response/ajax-response The problem I'm facing seems the same Stefan Lindner faced last year, whithout apparently finding a solution. I tried everything he tried. See link: http://www.nabble.com/AjaxSubmitButton-and-Umlauts-with-ISO-8859-1-%28Wicket-2%29-tf2622064.html I could migrate the whole application to UTF-8, but I would't do that for a single textarea in a single page... :-) It's the only page that needs non-English input. Any suggestion? Thanks a lot, Fabio Fioretti - WindoM On 10/21/07, Matej Knopp [EMAIL PROTECTED] wrote: I don't know tbh. I believe the request body is encoded in UTF-8. People usually use UTF-8, so no-one was complaining before. Can't you just use UTF-8? It's much safer than latin1. -Matej On 10/20/07, Johan Compagner [EMAIL PROTECTED] wrote: are you configuring wicket and you appserver correctly? in wicket you have to set the encoding you want to use why not just use utf8? else matej? How does the ajax submit work with encoding? It is still a normal post and how do we interpret it? On 10/19/07, Fabio Fioretti [EMAIL PROTECTED] wrote: Hi all, thanks in advance for your time and suggestions. I'm building a really simple page made up of a form with a text area and a submit button (instance of Button). An AjaxFormSubmitBehavior that performs the save operation is added to the button. The page is encoded as follows: meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1 Everything works fine until a user submits a non-English text (French or Spanish, with characters like íéñ, still supported by the ISO-8859-1 encoding): all non-English characters are scrambled. What appears weird to me is that the problem doesn't happen if I use, for example, a SubmitLink instead of an Ajax-enabled Button. This makes me point to Ajax as the responsible, and to the fact that Wicket uses UTF-8 for requests... but I really have no clue about how to fix it. Any idea? Thank you very much and have a nice week-end. Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird Ajax non-English characters encoding problem.
PS: I'm using Wicket 1.2.6. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weird Ajax non-English characters encoding problem.
Hi all, thanks in advance for your time and suggestions. I'm building a really simple page made up of a form with a text area and a submit button (instance of Button). An AjaxFormSubmitBehavior that performs the save operation is added to the button. The page is encoded as follows: meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1 Everything works fine until a user submits a non-English text (French or Spanish, with characters like íéñ, still supported by the ISO-8859-1 encoding): all non-English characters are scrambled. What appears weird to me is that the problem doesn't happen if I use, for example, a SubmitLink instead of an Ajax-enabled Button. This makes me point to Ajax as the responsible, and to the fact that Wicket uses UTF-8 for requests... but I really have no clue about how to fix it. Any idea? Thank you very much and have a nice week-end. Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundPropertyModel stops working when form validation fails.
On 10/6/07, Kent Tong [EMAIL PROTECTED] wrote: Even though you're not using wantOnSelectionChangedNotifications(), what I said applies: you need to call clearInput() like: [CUT] recommendationForm.clearInput(); //THIS LINE IS WHAT YOU NEED You were right Kent, thanks a lot! Calling clearInput() in the updating behavior really fixes the problem. What I miss now is why the CompoundPropertyModel breaks if the form is not manually reset by calling clearInput(). Is it a bug or a feature? :) Thank you for your time and precious help. Kindest regards, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundPropertyModel stops working when form validation fails.
On 10/5/07, Eelco Hillenius [EMAIL PROTECTED] wrote: *BUT*, when the user edits one of the recommendations making errors, tries to save it and form validation fails, the panel's CompoundPropertyModel seems to detach from the underlying AbstractModel and, if the user selects another choice on the ListChoice, the form is refreshed but it keeps showing data of the recommendation instance that failed validation. Not sure what this could be. Would you be able to create a test case or quickstart project that shows the bug? Given that calling form.clearInput() inside ListChoice's updating behavior solves the problem, is it still useful to create a test case to show CompoundPropertyModel's detachment or is it explainable now? I'm still missing an explanation, but probably you are not (and in this case, please share :-). Thanks a lot, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TabbedPanel with image tabs
On 10/7/07, Erik van Oosten [EMAIL PROTECTED] wrote: You can override a method on TabbedPanel to create the component that is put in the tab. I can not look it up now, but can do so later if you want. The method you are talking about is newLink. Kindest regards, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundPropertyModel stops working when form validation fails.
On 10/5/07, Kent Tong [EMAIL PROTECTED] wrote: Hello, thanks for your reply. I suppose you're using wantOnSelectionChangedNotifications() to trigger the refresh? No, I'm not. The ListChoice uses the same AbstractModel on which the panel inside the form builds its CompoundPropertyModel (see my previous posts): when user's selection changes, the AbstractModel correctly replaces its object with the newly selected instance and the form gets refreshed by an AjaxFormComponentUpdatingBehavior (attached to ListChoice's onclick event) to display the new instance (read from the same AbstractModel). Everything works really smooth: the user selects a recommendation from the list, he edits it, saves it, then he clicks on another recommendation from the list and edits this other one, and so on. *BUT*, when the user edits one of the recommendations making errors, tries to save it and form validation fails, the panel's CompoundPropertyModel seems to detach from the underlying AbstractModel and, if the user selects another choice on the ListChoice, the form is refreshed but it keeps showing data of the recommendation instance that failed validation. Any suggestion would be really appreciated, because maybe I'm missing something about the inner mechanisms of Wicket. Thank you all for any help, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundPropertyModel stops working when form validation fails.
P.S.: I'm using Wicket 1.2.6. Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CompoundPropertyModel stops working when form validation fails.
Hi all, thanks for your time and for keeping up this precious users' list. I have a page with a page-global currentRecommendation variable. The instance of this variable is updated by selecting one of the entries of a ListChoice; basically, the ListChoice deals with a list of recommendations instances and sets currentRecommendation to the one selected by the user. When a recommendation is selected, its data are loaded and displayed in a recommendationForm (contained in the same page) defined like this: recommendationForm = new Form(recommendationForm); The form contains a custom recommendationPanel which is linked to the currentRecommendation instance by a CompoundPropertyModel built on an AbstractReadOnlyModel, just like this: IModel recommendationModel = new AbstractReadOnlyModel() { @Override public Object getObject(Component component) { return currentRecommendation; } }; recommendationPanel = new CustomPanel(recommendationPanel, new CompoundPropertyModel(recommendationModel)); The problem is that when the form is submitted and validation *fails*, the CompoundPropertyModel of the recommendationPanel seems to disconnect from the currentRecommendation instance, because clicking on a different entry of the ListChoice mentioned above still refreshes the form but doesn't update the data contained in it anymore. In other words, the underlying currentRecommendation instance keeps changing correctly on ListChoice selection change (and the AbstractReadOnlyModel correctly picks up the selected instance), but the form (i.e. the panel contained in it) keeps displaying the instance that failed validation and doesn't show the newly selected recommendation instance anymore. The whole thing happens only when form validation fails. What am I missing? Thanks a lot for your help, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundPropertyModel stops working when form validation fails.
On 10/3/07, Martin-2 [EMAIL PROTECTED] wrote: Hi, Hi, thanks for the quick reply. if I understand correctly, the page variable and the panel model should always point to the same thing. Right. I suggest you give your page a model with currentRecommendation as model object. Then construct your panel with the same model instance as the page (or wrap it with an IChainingModel) and get rid of the page wide variable. I can't do that because my page is rather complex and it deals with at least two different kinds of objects. That's why I choose to have the currentRecommendation page variable instead, and a panel inside the related form that deals with the variable through the CompoundPropertyModel. The form's onSubmit() would be like: selectedValue = obtainSelectedValue(); getPage().getModel().setObject(selectedValue); setResponsePage(getPage()); so setting the page's model object to the choice the user selected, and only setting it if validation succeeds. I don't think this could solve my problem because: 1) I don't want the whole page to be refreshed or reloaded but only the panel that deals with currentRecommendation; 2) more important, I don't want the panel to be refreshed only if validation succeeds; I want it to always reflect user's selection from the ListChoice, i.e. the currentRecommendation which is the model object of the panel. The problem here is that, when form validation fails, the panel (which is contained in the form) stops responding to user's selections on the ListChoice as if its model loses the pointer to currentRecommendation. I hope I've been clear enough, 'cause it's not so easy to explain... Thanks a lot for your help! Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep inserted data on AjaxTabbedPanel tab switching.
On 9/21/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you have to override newlink on the tabbedpanel and return a submitlink instead Nice, this worked just fine! also, really, for situations like this it doesnt make sense to use a server-side panel. use client side tabs like what jquery provides instead - it works much better with forms. I agree, but this is not the case: I simplified the situation to frame the question more easily, but it's more complex in reality. Thanks a lot for your precious help, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]