Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Ah, our old friends 'enclosures'!
Problem is that a component inside an enclosure is really inside it only
during rendering of its markup.
But the strategy walking through the component hierarchy to render all headers
doesn't know anything about that enclosure o_O
As it has been written many times on this list, enclosures are best avoided in
anything than the simplest setup.
Have fun
Sven
Am 21. Januar 2020 09:14:28 MEZ schrieb Rob Audenaerde
:
>Hi Sven,
>
>Thanks for double-checking!
>
>The weird thing is that I thought this solved my problem, but when I
>tried
>to create the quickstart; I couldn't reproduce it either :o. I seem to
>have
>been mistakenly assuming it was this piece of code that fixed the
>problem.
>
>So I tried to build it more towards our application and I saw a
> that causes this behavior (the
>isVisibleInHierarchy() is
>not working there).
>
>I attached the quickstart for those who want to experiment with it.
>
>-Rob
>
>On Mon, Jan 20, 2020 at 7:17 PM Sven Meier wrote:
>
>> Hi Rob,
>>
>> actually I wasn't able to reproduce the problem on a second try (not
>> sure what I tested before).
>>
>> Can you create a a quickstart showing the problem?
>>
>> Sven
>>
>> On 20.01.20 13:18, Sven Meier wrote:
>> > Hi Rob,
>> >
>> >> the 'correct' way to solve this?
>> >
>> > the component is explicitly added to the Ajax request for an
>update,
>> > but decides to hide itself in onConfigure().
>> > Perfectly valid usecase IMHO, but the head will be rendered
>> > nevertheless :/
>> >
>> > Just tested with 7.x, 8.x and master, this seems to have been that
>way
>> > forever.
>> > But maybe we can improve that in Wicket core?
>> >
>> > Sven
>> >
>> >
>> > On 20.01.20 10:36, Rob Audenaerde wrote:
>> >> Hi all,
>> >>
>> >> I recently got some javascript errors that came from behaviors of
>> >> components that where triggered to be visible or invisible in the
>dom
>> >> (using onConfigure()) in an ajax request.
>> >>
>> >> Typically something like:
>> >>
>> >> Wicket.Ajax: Cannot bind a listener for event "change" on element
>> >> "format1dd" because the element is not in the DOM
>> >>
>> >> I solve this by adding an isVisibleInHierarchy() check in the
>> >> renderHead()
>> >> like this:
>> >>
>> >> @Override
>> >>
>> >> public void renderHead(final Component component, final
>IHeaderResponse
>> >> response) {
>> >> if (component.isVisibleInHierarchy()) {
>> >> super.renderHead(component, response);
>> >> }
>> >> }
>> >>
>> >> I was wondering if this is the 'correct' way to solve this? Or am
>I
>> >> doing
>> >> something wrong?
>> >>
>> >> Please advise :)
>> >>
>> >> -Rob
>> >>
>> >
>> >
>-
>> > 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: Need an event later than 'done'
Hi, I know this is not bulletproof but I always add a timeOut to hiding the veil, usually 300, 400 milliseconds, so that there is some margin for AJAX request to finish. Also some AJAX requests are so fast that veil + almost not visible. spinner is On Tue, Jan 21, 2020 at 11:59 PM Entropy wrote: > That seems promising. If you could look how you did it in your other > project > that would be great. I suppose if I could get access to the response XML I > could look for the redirect in that. I'm not sure where it is though or > even if it's provided to this event. > > -- > Sent from: > http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards - Ernesto Reinaldo Barreiro
Re: StringResourceModel parameter and AJAX update
Hi,
Instead of passing as parameter selectedUser try passing
new IModel {
getObject() {
return selectedUser;
}
}
as parameter. If you are using wicket 7.x then instead of IModel you could
use an AbstractReadonlyModel
On Tue, Jan 21, 2020 at 11:31 PM Zbynek Vavros
wrote:
> Hi,
>
> just simple use-case but I can't figure it out.
>
> I have DropDownChoice that selects User and Label having
> StringResourceModel where the parameter (new
> StringResourceModel(...).setParameter(selectedUser)) is the selected user.
> How do I update the Label's model so that it reflects User selected via
> AJAX?
>
> Thanks,
> Zbynek
>
--
Regards - Ernesto Reinaldo Barreiro
Re: Need an event later than 'done'
That seems promising. If you could look how you did it in your other project that would be great. I suppose if I could get access to the response XML I could look for the redirect in that. I'm not sure where it is though or even if it's provided to this event. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
StringResourceModel parameter and AJAX update
Hi, just simple use-case but I can't figure it out. I have DropDownChoice that selects User and Label having StringResourceModel where the parameter (new StringResourceModel(...).setParameter(selectedUser)) is the selected user. How do I update the Label's model so that it reflects User selected via AJAX? Thanks, Zbynek
Re: Need an event later than 'done'
Hi Entropy,
the trick is do keep the veil up whenever a redirect happens as the
result of an Ajax request.
Similar to what wicket-ajax-jquery.js is doing with it's Ajax indicator:
if (attrs.i && context.isRedirecting !== true) {
Wicket.DOM.hideIncrementally(attrs.i);
}
I have to look up how I solved that in one of my projects - regretfully
Ajax listeners do not have access to that "isRedirecting" flag.
Hope this helps
Sven
On 21.01.20 21:19, Entropy wrote:
In our app we display a veil after any button click that goes to the server
to prevent users double-submitting. Which they do. Alot. Double-submits
cause a variety of mischief for us ranging from StaleObjectExceptions in
hibernate to wicket exceptions about buttons not being enabled and others.
So we add the veil, and then (for ajax) close it thusly:
Wicket.Event.subscribe('/ajax/call/done',
function(jqEvent, attributes, jqXHR, errorThrown, textStatus) {
// console.log("done");
if(attributes) {
if(attributes.event) {
if(isVeiled(attributes.event.currentTarget)) {
closeVeil();
}
}
}
}
);
The problem is that this /ajax/call/done doesn't seem to fire when the
request is REALLY done, but rather a bit BEFORE it's done. We're getting
the same behavior, especially when an ajax event transitions from one page
to the next. The veil unloads, and there's a pause just before the redirect
kicks in during which the user assumes the same page is being seen and their
click was ignored...so they click again.
Is there a better/later event during which i can unload the veil? A
/ajax/call/really_done?
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
-
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
Need an event later than 'done'
In our app we display a veil after any button click that goes to the server
to prevent users double-submitting. Which they do. Alot. Double-submits
cause a variety of mischief for us ranging from StaleObjectExceptions in
hibernate to wicket exceptions about buttons not being enabled and others.
So we add the veil, and then (for ajax) close it thusly:
Wicket.Event.subscribe('/ajax/call/done',
function(jqEvent, attributes, jqXHR, errorThrown, textStatus) {
// console.log("done");
if(attributes) {
if(attributes.event) {
if(isVeiled(attributes.event.currentTarget)) {
closeVeil();
}
}
}
}
);
The problem is that this /ajax/call/done doesn't seem to fire when the
request is REALLY done, but rather a bit BEFORE it's done. We're getting
the same behavior, especially when an ajax event transitions from one page
to the next. The veil unloads, and there's a pause just before the redirect
kicks in during which the user assumes the same page is being seen and their
click was ignored...so they click again.
Is there a better/later event during which i can unload the veil? A
/ajax/call/really_done?
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Call for presentations for ApacheCon North America 2020 now open
Dear Apache enthusiast, (You’re receiving this message because you are subscribed to one or more project mailing lists at the Apache Software Foundation.) The call for presentations for ApacheCon North America 2020 is now open at https://apachecon.com/acna2020/cfp ApacheCon will be held at the Sheraton, New Orleans, September 28th through October 2nd, 2020. As in past years, ApacheCon will feature tracks focusing on the various technologies within the Apache ecosystem, and so the call for presentations will ask you to select one of those tracks, or “General” if the content falls outside of one of our already-organized tracks. These tracks are: Karaf Internet of Things Fineract Community Content Delivery Solr/Lucene (Search) Gobblin/Big Data Integration Ignite Observability Cloudstack Geospatial Graph Camel/Integration Flagon Tomcat Cassandra Groovy Web/httpd General/Other The CFP will close Friday, May 1, 2020 8:00 AM (America/New_York time). Submit early, submit often, at https://apachecon.com/acna2020/cfp Rich, for the ApacheCon Planners - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Hi,
I don't know if it is related or not but I have experienced a similar
problem while using borders. I don't remember the exact situation but I can
try to dig our code base and find out what was it.
On Tue, Jan 21, 2020 at 10:14 AM Rob Audenaerde
wrote:
> Hi Sven,
>
> Thanks for double-checking!
>
> The weird thing is that I thought this solved my problem, but when I tried
> to create the quickstart; I couldn't reproduce it either :o. I seem to have
> been mistakenly assuming it was this piece of code that fixed the problem.
>
> So I tried to build it more towards our application and I saw a
> that causes this behavior (the isVisibleInHierarchy() is
> not working there).
>
> I attached the quickstart for those who want to experiment with it.
>
> -Rob
>
> On Mon, Jan 20, 2020 at 7:17 PM Sven Meier wrote:
>
>> Hi Rob,
>>
>> actually I wasn't able to reproduce the problem on a second try (not
>> sure what I tested before).
>>
>> Can you create a a quickstart showing the problem?
>>
>> Sven
>>
>> On 20.01.20 13:18, Sven Meier wrote:
>> > Hi Rob,
>> >
>> >> the 'correct' way to solve this?
>> >
>> > the component is explicitly added to the Ajax request for an update,
>> > but decides to hide itself in onConfigure().
>> > Perfectly valid usecase IMHO, but the head will be rendered
>> > nevertheless :/
>> >
>> > Just tested with 7.x, 8.x and master, this seems to have been that way
>> > forever.
>> > But maybe we can improve that in Wicket core?
>> >
>> > Sven
>> >
>> >
>> > On 20.01.20 10:36, Rob Audenaerde wrote:
>> >> Hi all,
>> >>
>> >> I recently got some javascript errors that came from behaviors of
>> >> components that where triggered to be visible or invisible in the dom
>> >> (using onConfigure()) in an ajax request.
>> >>
>> >> Typically something like:
>> >>
>> >> Wicket.Ajax: Cannot bind a listener for event "change" on element
>> >> "format1dd" because the element is not in the DOM
>> >>
>> >> I solve this by adding an isVisibleInHierarchy() check in the
>> >> renderHead()
>> >> like this:
>> >>
>> >> @Override
>> >>
>> >> public void renderHead(final Component component, final IHeaderResponse
>> >> response) {
>> >> if (component.isVisibleInHierarchy()) {
>> >> super.renderHead(component, response);
>> >> }
>> >> }
>> >>
>> >> I was wondering if this is the 'correct' way to solve this? Or am I
>> >> doing
>> >> something wrong?
>> >>
>> >> Please advise :)
>> >>
>> >> -Rob
>> >>
>> >
>> > -
>> > 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
--
Regards - Ernesto Reinaldo Barreiro
Re: Wicket and Chat Bots
Well, sounds like a good plan! Wicket was originally conceived as a VoiceXML framework by Jonathan Locke (if you go back long enough in the history you'll find references to com.voicetribe packages), but he pivoted to HTML when he needed to build a website. So Wicket has been developed with this in mind. That is why there's this markup.html package, and Component itself doesn't know (much) of HTML processing, and there's a RequestCycle and a WebRequestCycle, an Application and WebApplication, a Page and a WebPage, etc. I'd like to see this explored further (preferably under an ASL to keep it compatible with the ASF so maybe in the future we can adopt it), as I have some interest in building Slack bots which are similar. Martijn On Tue, Jan 21, 2020 at 3:30 AM Илья Нарыжный wrote: > > Hello, > > I'm looking for some feedback from Wicket experienced devs and, > potentially, some team-members who will love the idea I'm going to > describe. > > We in Orienteer pretty frequently work with chat-bots for Facebook, > Telegram and etc. > One of our module was open-sourced: > https://github.com/OrienteerBAP/OTelegramBot > Another one still closed, but available as an Orienteer module for > free to download: graph-based description of an algorithm for a > Facebook bot. (We are going to open sources soon). > > So, even currently, we use Wicket core entities/lifecycles > (RequestCycle, WebSession, Application and etc) during actual bot > interactions with users through Facebook messenger or Telegram. And > now we are thinking about making one more step: use wicket rendering > mechanism for preparing bot's responses. Response is not only text > with markdown - it can include buttons, tables with paging and etc. So > idea is that Wicket will generate a layout of response in XML and the > corresponding adaptor will convert that layout to > Messanger/Telegram/WhatsUp/Viber etc. Using markup variations might > help to take into account specifics of a particular messaging > platform. > > Please let me know what do you think about the idea. > If it's good enough and viable - it will be definitely Open Source. > > Thanks, > Ilya > - > Orienteer(http://orienteer.org) - open source Business Application Platform > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Hi Sven,
Thanks for double-checking!
The weird thing is that I thought this solved my problem, but when I tried
to create the quickstart; I couldn't reproduce it either :o. I seem to have
been mistakenly assuming it was this piece of code that fixed the problem.
So I tried to build it more towards our application and I saw a
that causes this behavior (the isVisibleInHierarchy() is
not working there).
I attached the quickstart for those who want to experiment with it.
-Rob
On Mon, Jan 20, 2020 at 7:17 PM Sven Meier wrote:
> Hi Rob,
>
> actually I wasn't able to reproduce the problem on a second try (not
> sure what I tested before).
>
> Can you create a a quickstart showing the problem?
>
> Sven
>
> On 20.01.20 13:18, Sven Meier wrote:
> > Hi Rob,
> >
> >> the 'correct' way to solve this?
> >
> > the component is explicitly added to the Ajax request for an update,
> > but decides to hide itself in onConfigure().
> > Perfectly valid usecase IMHO, but the head will be rendered
> > nevertheless :/
> >
> > Just tested with 7.x, 8.x and master, this seems to have been that way
> > forever.
> > But maybe we can improve that in Wicket core?
> >
> > Sven
> >
> >
> > On 20.01.20 10:36, Rob Audenaerde wrote:
> >> Hi all,
> >>
> >> I recently got some javascript errors that came from behaviors of
> >> components that where triggered to be visible or invisible in the dom
> >> (using onConfigure()) in an ajax request.
> >>
> >> Typically something like:
> >>
> >> Wicket.Ajax: Cannot bind a listener for event "change" on element
> >> "format1dd" because the element is not in the DOM
> >>
> >> I solve this by adding an isVisibleInHierarchy() check in the
> >> renderHead()
> >> like this:
> >>
> >> @Override
> >>
> >> public void renderHead(final Component component, final IHeaderResponse
> >> response) {
> >> if (component.isVisibleInHierarchy()) {
> >> super.renderHead(component, response);
> >> }
> >> }
> >>
> >> I was wondering if this is the 'correct' way to solve this? Or am I
> >> doing
> >> something wrong?
> >>
> >> Please advise :)
> >>
> >> -Rob
> >>
> >
> > -
> > 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
>
>
visible.bz2
Description: application/bzip
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
