Re: Problem with WebRequestCodingStrategy's and mobile phones
These phone signal jammers are available at a very reasonable price. You can buy this phone signal jammer very easily. As this service takes nominal charges on the network, so you would need to spend a little amount to get complete peace of mind when you are not willing to get disturbed. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Problem-with-WebRequestCodingStrategy-s-and-mobile-phones-tp1877503p4662752.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: Generic busy indicator - override for AjaxSelfUpdatingTimerBehavior
Hi, Please give more details what exactly is the problem. On Thu, Dec 5, 2013 at 8:30 AM, Marieke Vandamme marieke.vanda...@tvh.bewrote: Dear wicket users, We are using the Generic busy indicator found on the wiki to have a busy indicator for every ajax event. https://cwiki.apache.org/confluence/display/WICKET/Generic+Busy+Indicator+%28for+both+Ajax+and+non-Ajax+submits%29# In that article on the wiki, it's also described how to override that functionality for a specific ajax event. /var clickedElement = (window.event) ? event.srcElement : eventData.target;/ Afterwards the clickedElement can be checked to see if the indicator needs to be shown or not. This is all working fine, but now we have a case where we want to use AjaxSelfUpdatingTimerBehavior. Then we have no clickedElement. Would somebody have an idea on how it's possible to retrieve the element that needs to be updated in the javascript functions for busy indicator? Thanks !! Kind regards, Marieke -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Generic-busy-indicator-override-for-AjaxSelfUpdatingTimerBehavior-tp4662800.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: Generic busy indicator - override for AjaxSelfUpdatingTimerBehavior
Hi,
Okay, I'll do my best to explain more in detail.
When doing an ajax call, we want to show a busy indicator on the page, so
that the user knows that something is happening and that he must wait for
the ajax response. This can be done by adding the Generic busy indicator (as
described on the wiki page I linked above). This binds the event before an
ajax call with following code:
/ Wicket.Event.subscribe('/ajax/call/beforeSend', function( attributes,
jqXHR, settings ) { showBusysign() });/
For some ajax events, it's not needed to show the busy indators. Now we have
such a case, with a timer, and we don't want to disturb the customer when
doing the ajax call. On the wiki page with the example, it's explained that
for specific ajax calls, you can check things, so that the indicator is not
showing. But the example is for AjaxLinks, where you have an element that
was clicked, and that element can be retrieved with event.srcElement in
javascript. We use the AjaxSelfUpdatingTimerBehavior, so we don't have an
element that is clicked.
Is there a way that we can retrieve the element that the timer is put on?
Something like event.srcElement?
I wanted to comment on the wiki article with this question too, but found no
way to add comment..
Thanks again! Kind Regards, Marieke
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Generic-busy-indicator-override-for-AjaxSelfUpdatingTimerBehavior-tp4662800p4662803.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: Generic busy indicator - override for AjaxSelfUpdatingTimerBehavior
Hi,
On Thu, Dec 5, 2013 at 2:58 PM, Marieke Vandamme marieke.vanda...@tvh.bewrote:
Hi,
Okay, I'll do my best to explain more in detail.
When doing an ajax call, we want to show a busy indicator on the page, so
that the user knows that something is happening and that he must wait for
the ajax response. This can be done by adding the Generic busy indicator
(as
described on the wiki page I linked above). This binds the event before an
ajax call with following code:
/ Wicket.Event.subscribe('/ajax/call/beforeSend', function( attributes,
jqXHR, settings ) { showBusysign() });/
For some ajax events, it's not needed to show the busy indators. Now we
have
such a case, with a timer, and we don't want to disturb the customer when
doing the ajax call. On the wiki page with the example, it's explained that
for specific ajax calls, you can check things, so that the indicator is not
showing. But the example is for AjaxLinks, where you have an element that
was clicked, and that element can be retrieved with event.srcElement in
javascript. We use the AjaxSelfUpdatingTimerBehavior, so we don't have an
element that is clicked.
Is there a way that we can retrieve the element that the timer is put on?
Something like event.srcElement?
Yes, there is: document.getElementById(attributes.c)
I wanted to comment on the wiki article with this question too, but found
no
way to add comment..
Thanks again! Kind Regards, Marieke
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Generic-busy-indicator-override-for-AjaxSelfUpdatingTimerBehavior-tp4662800p4662803.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: Generic busy indicator - override for AjaxSelfUpdatingTimerBehavior
Why just don't pass an attribute that means do not show progress... and
use the same for all AJAX action that do not need to show progress
On Thu, Dec 5, 2013 at 2:58 PM, Marieke Vandamme marieke.vanda...@tvh.bewrote:
Hi,
Okay, I'll do my best to explain more in detail.
When doing an ajax call, we want to show a busy indicator on the page, so
that the user knows that something is happening and that he must wait for
the ajax response. This can be done by adding the Generic busy indicator
(as
described on the wiki page I linked above). This binds the event before an
ajax call with following code:
/ Wicket.Event.subscribe('/ajax/call/beforeSend', function( attributes,
jqXHR, settings ) { showBusysign() });/
For some ajax events, it's not needed to show the busy indators. Now we
have
such a case, with a timer, and we don't want to disturb the customer when
doing the ajax call. On the wiki page with the example, it's explained that
for specific ajax calls, you can check things, so that the indicator is not
showing. But the example is for AjaxLinks, where you have an element that
was clicked, and that element can be retrieved with event.srcElement in
javascript. We use the AjaxSelfUpdatingTimerBehavior, so we don't have an
element that is clicked.
Is there a way that we can retrieve the element that the timer is put on?
Something like event.srcElement?
I wanted to comment on the wiki article with this question too, but found
no
way to add comment..
Thanks again! Kind Regards, Marieke
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Generic-busy-indicator-override-for-AjaxSelfUpdatingTimerBehavior-tp4662800p4662803.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
--
Regards - Ernesto Reinaldo Barreiro
Re: Generic busy indicator - override for AjaxSelfUpdatingTimerBehavior
remove the don't
On Thu, Dec 5, 2013 at 3:30 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Why just don't pass an attribute that means do not show progress... and
use the same for all AJAX action that do not need to show progress
On Thu, Dec 5, 2013 at 2:58 PM, Marieke Vandamme
marieke.vanda...@tvh.bewrote:
Hi,
Okay, I'll do my best to explain more in detail.
When doing an ajax call, we want to show a busy indicator on the page, so
that the user knows that something is happening and that he must wait for
the ajax response. This can be done by adding the Generic busy indicator
(as
described on the wiki page I linked above). This binds the event before an
ajax call with following code:
/ Wicket.Event.subscribe('/ajax/call/beforeSend', function( attributes,
jqXHR, settings ) { showBusysign() });/
For some ajax events, it's not needed to show the busy indators. Now we
have
such a case, with a timer, and we don't want to disturb the customer when
doing the ajax call. On the wiki page with the example, it's explained
that
for specific ajax calls, you can check things, so that the indicator is
not
showing. But the example is for AjaxLinks, where you have an element that
was clicked, and that element can be retrieved with event.srcElement in
javascript. We use the AjaxSelfUpdatingTimerBehavior, so we don't have an
element that is clicked.
Is there a way that we can retrieve the element that the timer is put on?
Something like event.srcElement?
I wanted to comment on the wiki article with this question too, but found
no
way to add comment..
Thanks again! Kind Regards, Marieke
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Generic-busy-indicator-override-for-AjaxSelfUpdatingTimerBehavior-tp4662800p4662803.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
--
Regards - Ernesto Reinaldo Barreiro
--
Regards - Ernesto Reinaldo Barreiro
Wrong JavaDoc for FeedbackMessages#hasMessage(int)
Currently (as of 6.10.0) the JavaDoc on the FeedbackMessages#hasMessage(int) states that it returns true if and only if a message with the specified level was registered. However it relies on FeedbackMessage#isLevel(int) which in turn return true if whether the message level is greater than or equal to the given level. Isn't that contradicting? I registered an Error message for my form field and I have a new behavior checking for Warnings that performs its duties because an Error message is at a lever greater than the Warning level. ~ Thank you, Paul Bors
Re: Wrong JavaDoc for FeedbackMessages#hasMessage(int)
Hi, You are right. But I think we can only improve the javadoc. You will have to use org.apache.wicket.feedback.FeedbackMessages#hasMessage(org.apache.wicket.feedback.IFeedbackMessageFilter) with a filter that makes exact match. I have the feeling that we added such filter but I can only see org.apache.wicket.feedback.ErrorLevelFeedbackMessageFilter that has the same behavior as #hasMessage(int). Please file a ticket and we will add it. On Thu, Dec 5, 2013 at 5:24 PM, Paul Bors p...@bors.ws wrote: Currently (as of 6.10.0) the JavaDoc on the FeedbackMessages#hasMessage(int) states that it returns true if and only if a message with the specified level was registered. However it relies on FeedbackMessage#isLevel(int) which in turn return true if whether the message level is greater than or equal to the given level. Isn't that contradicting? I registered an Error message for my form field and I have a new behavior checking for Warnings that performs its duties because an Error message is at a lever greater than the Warning level. ~ Thank you, Paul Bors
Re: Wrong JavaDoc for FeedbackMessages#hasMessage(int)
Yes, we are using the .FeedbackMessages#hasMessage(IFeedbackMessageFilter) as we had no other choice. I'll file a ticket with a pull request now that I got used to GitHub :) ~ Thank you, Paul Bors On Thu, Dec 5, 2013 at 11:39 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, You are right. But I think we can only improve the javadoc. You will have to use org.apache.wicket.feedback.FeedbackMessages#hasMessage(org.apache.wicket.feedback.IFeedbackMessageFilter) with a filter that makes exact match. I have the feeling that we added such filter but I can only see org.apache.wicket.feedback.ErrorLevelFeedbackMessageFilter that has the same behavior as #hasMessage(int). Please file a ticket and we will add it. On Thu, Dec 5, 2013 at 5:24 PM, Paul Bors p...@bors.ws wrote: Currently (as of 6.10.0) the JavaDoc on the FeedbackMessages#hasMessage(int) states that it returns true if and only if a message with the specified level was registered. However it relies on FeedbackMessage#isLevel(int) which in turn return true if whether the message level is greater than or equal to the given level. Isn't that contradicting? I registered an Error message for my form field and I have a new behavior checking for Warnings that performs its duties because an Error message is at a lever greater than the Warning level. ~ Thank you, Paul Bors
Re: Wicket CDI Status
Thanks Emond, I will watch the progress and report back. For now.. I'm ignoring the warnings and using a snapshot from glassfish. I'm using CDI just for EntityManager injection..and it's just RequestScoped. So.. from what I saw in the current version, the biggest problem would be if it was context oriented. Regards, Diogo C. On Wed, Dec 4, 2013 at 7:01 PM, Emond Papegaaij emond.papega...@gmail.com wrote: Hi Diogo, Please note that wicket-cdi-1.1 is still experimental. I do have high confidence it will work fine, but it has not been tested extensively. The API is mostly compatible with the current wicket-cdi module. One of the changes is that the constructor of the CdiConfiguration no longer takes a BeanManager. CDI 1.1 has several portable ways of looking up this BeanManager. A fallback is added (see CdiConfiguration), in case your environment does not provide any of the portable lookup methods, but Glassfish should. Also, it is no longer possible to disable injection of various Wicket classes. Components, behaviors, sessions and the application are always injected. A major difference in behavior is the way conversations are propagated. The current cdi module uses non-portable code (which only works with Weld) to propagate the conversation. wicket-cdi-1.1 always propagates the conversation via the url (with the cid query-parameter), which is portable across all CDI 1.1 providers. As Martin mentioned, wicket-cdi-1.1 requires a recent version of Weld (if used with Weld). Weld 2.1.1 (which has not yet been released) has some fixes regarding warning floods (https://issues.jboss.org/browse/WELD-1547). Until then, you either have to ignore the warnings or lower the logging level. To use wicket-cdi-1.1, once wicket 6.13 is released, add the following dependency: dependency groupIdorg.apache.wicket/groupId artifactIdwicket-cdi-1.1/artifactId version0.2/version /dependency Until then, you can test with 0.2-SNAPSHOT. You can find the details for the snapshot repository on our download page. If you find any issues with wicket-cdi-1.1, please file JIRA issues and assign them to me. Best regards, Emond Papegaaij On Wed, Dec 4, 2013 at 7:02 PM, Diogo Casado diogocas...@gmail.com wrote: It looks like it is running with glassfish4 snapshot 4.1 b4m1. They use the latest version of weld on it. Well.. I will continue this way.. Do you have an idea on when we will have v6.13 with cdi1.1? Thank you very much. On Wed, Dec 4, 2013 at 2:07 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I am not very into CDI business but here are some solutions: - upgrade Weld to 2.1.0 in Glassfish 4, if this is possible. The exception is caused by a bug in Weld 2.0.x - use Wicket 6.9.0. This will work unless you use @Inject in anonymous Wicket components. I personally never thought about this pattern before Wicket 6.9.1. I guess you don't use it too - Wicket 6.13.0 will bring wicket-cdi-1.1 module. But again it will work only if you use it with Weld 2.1.x On Wed, Dec 4, 2013 at 5:01 PM, Diogo Casado diogocas...@gmail.com wrote: Hello guys.. I'm setting up a Glassfish4 environment with wicket 6.12.0 and I previously started using cdi to inject entity managers. On Tomee, cdi was working but I decided that this particular application will need a more robust JavaEE server (specially because of OpenJPA slow pace). Anyway.. I'm getting warnings everywhere and specially this exception that just broke the app: WELD-70 Simple bean [EnhancedAnnotatedTypeImpl] class comLoginPage$1 cannot be a non-static inner class The offending class is basically a anonymous Form.. I conclude that any anonymous class would cause this. Found this ticket: https://issues.apache.org/jira/browse/WICKET-5264 I guess it happened before and was fixed in v6.9.0 but I'm still facing this issue with v6.12.0. So basically.. what's the best option: - Apply some fix to this situation; - Stick with a JavaEE6 with Glassfish3 while using v6.x + cdi and in near future go for JavaEE7 Glassfish4 + Wicket v7.x cdi 1.1 (when ready) - Should I forget cdi =\ I appreciate guidance. Thanks. - 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: Wicket CDI Status
The new module should be fully functional, including all scopes. The performance should be much better than with the old module, due to InjectionTarget caching. The biggest changes are in conversation propagation. If you do not use the conversation scope, the transition to the new module should be very smooth. Best regards, Emond Op 5 dec. 2013 20:24 schreef Diogo Casado diogocas...@gmail.com: Thanks Emond, I will watch the progress and report back. For now.. I'm ignoring the warnings and using a snapshot from glassfish. I'm using CDI just for EntityManager injection..and it's just RequestScoped. So.. from what I saw in the current version, the biggest problem would be if it was context oriented. Regards, Diogo C. On Wed, Dec 4, 2013 at 7:01 PM, Emond Papegaaij emond.papega...@gmail.com wrote: Hi Diogo, Please note that wicket-cdi-1.1 is still experimental. I do have high confidence it will work fine, but it has not been tested extensively. The API is mostly compatible with the current wicket-cdi module. One of the changes is that the constructor of the CdiConfiguration no longer takes a BeanManager. CDI 1.1 has several portable ways of looking up this BeanManager. A fallback is added (see CdiConfiguration), in case your environment does not provide any of the portable lookup methods, but Glassfish should. Also, it is no longer possible to disable injection of various Wicket classes. Components, behaviors, sessions and the application are always injected. A major difference in behavior is the way conversations are propagated. The current cdi module uses non-portable code (which only works with Weld) to propagate the conversation. wicket-cdi-1.1 always propagates the conversation via the url (with the cid query-parameter), which is portable across all CDI 1.1 providers. As Martin mentioned, wicket-cdi-1.1 requires a recent version of Weld (if used with Weld). Weld 2.1.1 (which has not yet been released) has some fixes regarding warning floods ( https://issues.jboss.org/browse/WELD-1547). Until then, you either have to ignore the warnings or lower the logging level. To use wicket-cdi-1.1, once wicket 6.13 is released, add the following dependency: dependency groupIdorg.apache.wicket/groupId artifactIdwicket-cdi-1.1/artifactId version0.2/version /dependency Until then, you can test with 0.2-SNAPSHOT. You can find the details for the snapshot repository on our download page. If you find any issues with wicket-cdi-1.1, please file JIRA issues and assign them to me. Best regards, Emond Papegaaij On Wed, Dec 4, 2013 at 7:02 PM, Diogo Casado diogocas...@gmail.com wrote: It looks like it is running with glassfish4 snapshot 4.1 b4m1. They use the latest version of weld on it. Well.. I will continue this way.. Do you have an idea on when we will have v6.13 with cdi1.1? Thank you very much. On Wed, Dec 4, 2013 at 2:07 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I am not very into CDI business but here are some solutions: - upgrade Weld to 2.1.0 in Glassfish 4, if this is possible. The exception is caused by a bug in Weld 2.0.x - use Wicket 6.9.0. This will work unless you use @Inject in anonymous Wicket components. I personally never thought about this pattern before Wicket 6.9.1. I guess you don't use it too - Wicket 6.13.0 will bring wicket-cdi-1.1 module. But again it will work only if you use it with Weld 2.1.x On Wed, Dec 4, 2013 at 5:01 PM, Diogo Casado diogocas...@gmail.com wrote: Hello guys.. I'm setting up a Glassfish4 environment with wicket 6.12.0 and I previously started using cdi to inject entity managers. On Tomee, cdi was working but I decided that this particular application will need a more robust JavaEE server (specially because of OpenJPA slow pace). Anyway.. I'm getting warnings everywhere and specially this exception that just broke the app: WELD-70 Simple bean [EnhancedAnnotatedTypeImpl] class comLoginPage$1 cannot be a non-static inner class The offending class is basically a anonymous Form.. I conclude that any anonymous class would cause this. Found this ticket: https://issues.apache.org/jira/browse/WICKET-5264 I guess it happened before and was fixed in v6.9.0 but I'm still facing this issue with v6.12.0. So basically.. what's the best option: - Apply some fix to this situation; - Stick with a JavaEE6 with Glassfish3 while using v6.x + cdi and in near future go for JavaEE7 Glassfish4 + Wicket v7.x cdi 1.1 (when ready) - Should I forget cdi =\ I appreciate guidance. Thanks. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
