Re: Browser/Client info navigatorJavaEnabled property returns undefined
Hi Martin, The issue is in Chrome browser. creared a Jira issue, below is the link. https://issues.apache.org/jira/browse/WICKET-6174 Regards, Ramesh -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Browser-Client-info-navigatorJavaEnabled-property-returns-undefined-tp4674794p4674824.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Draggable multiple containment
Hi Maxim, It should be achievable, using revert and accept/scope By reading your post, I suddently have a doubt, revert is not supposed to cancel the drop action. The element just go back to its original place but onDrop should still be fired. I have to double check tomorrow because implementing revert as a function seems to cancel drop event... weird (or i didn't paid attention) On May 31, 2016 19:34, "Maxim Solodovnik" wrote: > Hello Sebastien > > thanks for the reply :) > I'll try to describe my use case > > I do have file free panel, file/folder items on this panel can be *moved* > to other folders (there are unmovable root folders and trash) > everything works as expected > > now I need to add "display" panel > > I would like "file" item can be dropped to this panel BUT visually it > should *revert* to original place, but need to be processed by drop target. > So I cannot set revert option on draggable (files need to be able to be > moved) > I need to process file in onDrop method, then "visually revert it to the > original position" > is it too much? :))) > > On Tue, May 31, 2016 at 6:06 PM, Sebastien wrote: > > > Hi Maxim, > > > > Sorry for the late answer! > > > > "Droppable#onDrop, where you can reject the Draggable item/component" was > > actually misleading. > > IIRC it was supposed to mean "if the element is not reverted, then it is > > accepted ; and if the element is reverted then it is rejected by design" > > > > The most important question to me is: do you know in advance what element > > can be accepted or not ? (meaning can you recognized them with a special > > css class for instance or any data-* attribute?) > > > > 1/ In case of yes, please consider these droppable option (it can replace > > my previous draggable code snippet) > > http://api.jqueryui.com/droppable/#option-accept > > http://api.jqueryui.com/droppable/#option-scope > > > > 2/ in case of no... then consider case 1/ ;) > > > > In you need additional help on this, please describe a simple/concrete > > usecase so I can test further :) > > > > Best regards, > > Sebastien. > > > > > > On Thu, May 26, 2016 at 7:27 PM, Maxim Solodovnik > > wrote: > > > > > Hello Sebastien, > > > finally I found free time to continue this work :) > > > > > > Actually my question was regarding "Droppable#onDrop, where you can > > reject > > > the Draggable item/component", how this can be achieved? > > > > > > > > > -- > WBR > Maxim aka solomax >
Re: Draggable multiple containment
Hello Sebastien thanks for the reply :) I'll try to describe my use case I do have file free panel, file/folder items on this panel can be *moved* to other folders (there are unmovable root folders and trash) everything works as expected now I need to add "display" panel I would like "file" item can be dropped to this panel BUT visually it should *revert* to original place, but need to be processed by drop target. So I cannot set revert option on draggable (files need to be able to be moved) I need to process file in onDrop method, then "visually revert it to the original position" is it too much? :))) On Tue, May 31, 2016 at 6:06 PM, Sebastien wrote: > Hi Maxim, > > Sorry for the late answer! > > "Droppable#onDrop, where you can reject the Draggable item/component" was > actually misleading. > IIRC it was supposed to mean "if the element is not reverted, then it is > accepted ; and if the element is reverted then it is rejected by design" > > The most important question to me is: do you know in advance what element > can be accepted or not ? (meaning can you recognized them with a special > css class for instance or any data-* attribute?) > > 1/ In case of yes, please consider these droppable option (it can replace > my previous draggable code snippet) > http://api.jqueryui.com/droppable/#option-accept > http://api.jqueryui.com/droppable/#option-scope > > 2/ in case of no... then consider case 1/ ;) > > In you need additional help on this, please describe a simple/concrete > usecase so I can test further :) > > Best regards, > Sebastien. > > > On Thu, May 26, 2016 at 7:27 PM, Maxim Solodovnik > wrote: > > > Hello Sebastien, > > finally I found free time to continue this work :) > > > > Actually my question was regarding "Droppable#onDrop, where you can > reject > > the Draggable item/component", how this can be achieved? > > > -- WBR Maxim aka solomax
Re: Resource caching - validation of user entered version
Thanks for fast answer :) -- Daniel On Tue, May 31, 2016 at 4:54 PM, Martin Grigorov wrote: > Hi, > > The version is intended to be used by the browser for client side caching, > not by Wicket. That's why it is just stripped off by Wicket without any > validation. > Actually if Wicket rejects it then you won't be able to update your > resources in new application versions. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Tue, May 31, 2016 at 4:51 PM, Daniel Stoch > wrote: > >> Hi, >> >> By default Wicket (6.x) uses IResourceCachingStrategy which generates >> resource urls like this one: >> >> http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-1E0DAFB24FE33C93370DE13BF6FFE77F.js >> >> But as a user I can generate almost any version number in this url and >> it will be handled correctly by Wicket. For example these urls still >> work ok: >> >> http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-123.js >> >> http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver--alert('1');return >> false;.js >> >> Is it a desired behavior or maybe Wicket should reject such >> "incorrect" versions? Could it be some security issue? >> >> -- >> Best regards, >> Daniel >> >> - >> 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: Resource caching - validation of user entered version
Hi, The version is intended to be used by the browser for client side caching, not by Wicket. That's why it is just stripped off by Wicket without any validation. Actually if Wicket rejects it then you won't be able to update your resources in new application versions. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, May 31, 2016 at 4:51 PM, Daniel Stoch wrote: > Hi, > > By default Wicket (6.x) uses IResourceCachingStrategy which generates > resource urls like this one: > > http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-1E0DAFB24FE33C93370DE13BF6FFE77F.js > > But as a user I can generate almost any version number in this url and > it will be handled correctly by Wicket. For example these urls still > work ok: > > http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-123.js > > http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver--alert('1');return > false;.js > > Is it a desired behavior or maybe Wicket should reject such > "incorrect" versions? Could it be some security issue? > > -- > Best regards, > Daniel > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Resource caching - validation of user entered version
Hi, By default Wicket (6.x) uses IResourceCachingStrategy which generates resource urls like this one: http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-1E0DAFB24FE33C93370DE13BF6FFE77F.js But as a user I can generate almost any version number in this url and it will be handled correctly by Wicket. For example these urls still work ok: http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver-123.js http://host/myapp/wicket/resource/com.mycompany.BootstrapBehavior/js/timepicker/bootstrap-timepicker-ver--alert('1');return false;.js Is it a desired behavior or maybe Wicket should reject such "incorrect" versions? Could it be some security issue? -- Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Draggable multiple containment
Hi Maxim, Sorry for the late answer! "Droppable#onDrop, where you can reject the Draggable item/component" was actually misleading. IIRC it was supposed to mean "if the element is not reverted, then it is accepted ; and if the element is reverted then it is rejected by design" The most important question to me is: do you know in advance what element can be accepted or not ? (meaning can you recognized them with a special css class for instance or any data-* attribute?) 1/ In case of yes, please consider these droppable option (it can replace my previous draggable code snippet) http://api.jqueryui.com/droppable/#option-accept http://api.jqueryui.com/droppable/#option-scope 2/ in case of no... then consider case 1/ ;) In you need additional help on this, please describe a simple/concrete usecase so I can test further :) Best regards, Sebastien. On Thu, May 26, 2016 at 7:27 PM, Maxim Solodovnik wrote: > Hello Sebastien, > finally I found free time to continue this work :) > > Actually my question was regarding "Droppable#onDrop, where you can reject > the Draggable item/component", how this can be achieved? >
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 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 > > 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,
Re: [Released] PAX-Wicket 3.0.4 now out!
I see! Thank you! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, May 31, 2016 at 8:01 AM, nino martinez wael < nino.martinez.w...@gmail.com> wrote: > It's "just" models that automatically return a service type from the > osgi service registry, so for example the > > AbstractDetachableServiceModel > This model makes it easier to work with OSGi services in Wicket. It is > a LoadableDetachableModel that loads data via a Service accuired from > the Service Registry. > > Where T is the service class and E are the return Object > > It also have nice error handling if the service are unavailable.. > > Of course it's still possible to use @Inject as normally. Or mix them, > I'd personally prefer only one style per bundle though.. > > On Mon, May 30, 2016 at 1:16 PM, Martin Grigorov > wrote: > > Hi, > > > > Could you please share some more information about "Alternative Wicket > > Models preconfigured for OSGI (Martin Nybo Nielsen)" ? > > Thank you! > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Mon, May 30, 2016 at 12:52 PM, nino martinez wael < > > nino.martinez.w...@gmail.com> wrote: > > > >> PAX-Wicket 3.0.4, running Wicket OSGI style > >> > >> Main goal for this release are to bring PAX-Wicket to working state on > >> Apache Karaf 4.x, while retaining compability the other containers > >> > >> Major features > >> * Working with Karaf 4.x (Nino Martinez Wael) > >> * Working wik Wicket 6.22 (Nino Martinez Wael) > >> * Karaf Feature files for all samples (Nino Martinez Wael) > >> * Alternative Wicket Models preconfigured for OSGI (Martin Nybo Nielsen) > >> * Reworked Internals to provide better support (Christoph Läubrich) > >> * Integration tests for Apache Karaf added > >> > >> > >> KNOWN Issues > >> * Weaving hook has been disabled, it added dependencies to dynamic > imports. > >> > >> Thanks for OPS4J people for making this happen > >> > >> Want to know more about PAX-Wicket GO here: > >> > >> https://ops4j1.jira.com/wiki/display/paxwicket/Pax+Wicket > >> > >> -- > >> Best regards / Med venlig hilsen > >> Nino Martinez > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > -- > Best regards / Med venlig hilsen > Nino Martinez > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >