Re: Client side javascript listeners / HeaderItems / OnDomReadyHeaderItem
Hi Andrea, thanx for your feedback... Currently I'm researching more into AbstractDefaultAjaxBehaviors. My javascript which should be executed with priority is an ajax-call. So, it can be handled by Wicket itself. I've seen the default event of an AbstractDefaultAjaxBehavior is a 'ondomready', so that fits my needs. Also IAjaxCallListeners are looking very good to me, to have the listener-feature. Right now I'm facing the problem, how I can force my behavior beeing a singleton on page, but appling many IAjaxCallListeners to the updateAjaxAttributes() to support a list of success-handlers. Patrick Am 15.04.2015 um 12:17 schrieb andrea del bene: On 15/04/2015 11:02, Patrick Davids wrote: Hi all, is there something included as feature in Wickets HeaderItems, what I can use as kind of client-side javascript observer-listener pattern? For instance... I have components which relies on a on-dom-ready previous executed javascript, before the components internal javascripts can be executed. So, its a kind of mix of PriorityHeaderItem and OnDomReadyHeaderItem and fire mechanism, when the scripts with priority has been successfully executed. I would like to implement this feature as behavior, so multiple components on a page can have this pre-executed-javascript-behavior, and listen for a javascript execution done event. Have considered yet to use resource dependencies. You might create a resource specifying which resource it depends on must be rendered first. Than you can render it in your custom behavior. See chapter '16.6 Resource dependencies' of user guide. This javascript-code should also applied to the page only once, independently how often the behavior is added to my different components on page. I also need some sort of subscription code on javascript-side to get notified. To avoid multiple rendering of the same header item, class HeaderItem uses method getRenderTokens to check if the item has already been rendered. So if your heder item doesn't change (for example, the javascript code is always the same) it won't be rendered more than once. I already have some ideas to implement this, but would like to ask for framework-features or other inspirations, best practices or ideas, first. Thanx for feedback! Patrick - 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: ListenerInvocationNotAllowedException in wicket 6.19
Looks like there was a problem with non-printable character in HTML. If it doesn't show up again - that's it, solved. Thanks! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ListenerInvocationNotAllowedException-in-wicket-6-19-tp4670301p4670319.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: ListenerInvocationNotAllowedException in wicket 6.19
Great! Have fun! Martin Grigorov Freelancer, available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Apr 15, 2015 at 2:58 PM, ssamarin stepan.sama...@gmail.com wrote: Looks like there was a problem with non-printable character in HTML. If it doesn't show up again - that's it, solved. Thanks! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ListenerInvocationNotAllowedException-in-wicket-6-19-tp4670301p4670319.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: Veil on ajax which ends with redirect eventually
Hi,
Wicket hides the Ajax indicator at onComplete() callback [1].
The redirect is handled either at [2], [3] or [4]. All of those are
processed in the same thread (there is no usage of setTimeout()) so I
think the redirect should happen before the removal of the Ajax indicator.
I guess the loading of the new page takes some time and during that time
the JS of the current page is fully executed and that's why you see the old
page without the veil for some time.
I think it is OK to leave the veil (ajax indicator) in case of redirect for
all cases. We can just raise a flag in JS when a redirect is scheduled.
Let's see what others think.
File a ticket for improvement at our JIRA.
1.
https://github.com/apache/wicket/blob/f2bc2ba0985352c44a416f9174f01e88e87f53e5/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L699
2.
https://github.com/apache/wicket/blob/f2bc2ba0985352c44a416f9174f01e88e87f53e5/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L769
3.
https://github.com/apache/wicket/blob/f2bc2ba0985352c44a416f9174f01e88e87f53e5/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L793
4.
https://github.com/apache/wicket/blob/f2bc2ba0985352c44a416f9174f01e88e87f53e5/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L1241
Martin Grigorov
Freelancer, available for hire!
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Apr 15, 2015 at 11:03 AM, tomask79 tomas.klou...@embedit.cz wrote:
Hi guys,
in our wicket application we use standard framework mechanism for showing
veil on Ajax actions by implementing the interface IAjaxIndicatorAware.
It's
working fine until you've got situation when your on event method of
Ajax form component, for example, ends with setResponsePage redirect.
Something like this, typical scenario:
public void on(final AjaxRequestTarget target) {
if (conditionForRerender) {
target.add(...components...);
} else {
.
setResponsePage(MyClass, MyPageParams);
}
}
Problem is when final action of on method is redirect then our user see
the blocking veil just when Ajax works and not until the redirect is
done...:-(. It's because redirect isn't ajax, wicket does redirection to
result in that case.
The solution which I can come up with is not using the interface
IAjaxIndicatorAware and manipulate the veil manually by leaving the veil
shown even after ajax process, eventual redirect will render new page so
the
veil will be removed by redirection.
Anyway, I would prefer if *framework could take care of it*. Something like
this would be awesome:
public void on(final AjaxRequestTarget target) {
if (conditionForRerender) {
target.add(...components...);
} else {
.
*target.setLeaveVeilOpen(true);*
setResponsePage(MyClass, MyPageParams);
}
}
which would add into to ajax response information: Do not hide ajax
indicatorSo the redirection will be veiled as well.
Guys, please any suggestions to this?
Best Regards
Tomas
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Veil-on-ajax-which-ends-with-redirect-eventually-tp4670309.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
Client side javascript listeners / HeaderItems / OnDomReadyHeaderItem
Hi all, is there something included as feature in Wickets HeaderItems, what I can use as kind of client-side javascript observer-listener pattern? For instance... I have components which relies on a on-dom-ready previous executed javascript, before the components internal javascripts can be executed. So, its a kind of mix of PriorityHeaderItem and OnDomReadyHeaderItem and fire mechanism, when the scripts with priority has been successfully executed. I would like to implement this feature as behavior, so multiple components on a page can have this pre-executed-javascript-behavior, and listen for a javascript execution done event. This javascript-code should also applied to the page only once, independently how often the behavior is added to my different components on page. I also need some sort of subscription code on javascript-side to get notified. I already have some ideas to implement this, but would like to ask for framework-features or other inspirations, best practices or ideas, first. Thanx for feedback! Patrick - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
How to get a map of parameters of a request in wicket 6
Hi, In Wicket 1.4 we have following code snippet: final MapString, String[] params = getRequestCycle().getRequest().getParameterMap(); Wicket 6 doesn't have the capabilities of extracting a map. Is this assumption correct? I can only find a method that extracts the keys: final SetString parameterNames = getRequest().getRequestParameters().getParameterNames(); Do I have to built the map myself or is there a convenience function somewhere I overlooked? Thanks, David
Re: ListenerInvocationNotAllowedException in wicket 6.19
Well, Behaviour is the following: click once in navigator and wait. Components of the page are not refreshed at all but component page number is disabled in background. Clicking second time on same number in navigator produces an error because the component is disabled -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ListenerInvocationNotAllowedException-in-wicket-6-19-tp4670301p4670315.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
