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 > > <form-id>.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 > >> > > > |__ > >> > > > 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 > >> > > > > >> > > > >> > > >> > > > > >
