Re: Browser/Client info navigatorJavaEnabled property returns undefined

[ravala]

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

[Sebastien]

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

[Maxim Solodovnik]

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

[Daniel Stoch]

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

[Martin Grigorov]

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

[Daniel Stoch]

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

[Sebastien]

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.

[Fabio Fioretti]

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 

Re: [Released] PAX-Wicket 3.0.4 now out!

[Martin Grigorov]

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
>
>

Re: [Released] PAX-Wicket 3.0.4 now out!

[nino martinez wael]

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