I tend to think of the the "after render requires" as initializers, and the
ajaxResponseRenderer (ARR) callbacks as the place to do interaction.
I do not think of toggle calls like (show/hide timer) as real initializers.
We still use .require to get the client side module "injected" in the ARR,
but the type of the calls would be something that interacts with the module
(like toggle for instance).
--
Chris
On Mon, Nov 17, 2014 at 11:42 AM, Geoff Callender <
geoff.callender.jumpst...@gmail.com> wrote:
> Hey, hang on, Chris, weren't you the one who asked "can't you just use
> javascriptsupport to require and invoke your js module
> function?". That's what got me doubting the "rule of thumb" that I'd
> written! Am I missing your point?
>
> Cheers
>
> Geoff
>
>
> On 17 Nov 2014, at 8:56 pm, Chris Poulsen <mailingl...@nesluop.dk> wrote:
>
> > We're doing something like this in event handlers to perform callbacks
> >
> > void onSetupDialog( @RequestParameter( "params" ) JSONObject json )
> > {
> > initialLoad = false;
> >
> > extractParams( json );
> > ajaxResponseRenderer.addRender( "linkDialogModal",
> > ( ( org.apache.tapestry5.runtime.Component )
> > linkDialogModal )
> > .getComponentResources().getBody() );
> >
> > if( linkFields ) // link text in the text field to the address
> field
> > {
> > ajaxResponseRenderer.addCallback( new JavaScriptCallback()
> > {
> > @Override
> > public void run( JavaScriptSupport javascriptSupport )
> > {
> > javascriptSupport.require(
> > "components/editor/link-dialog" )
> > .invoke( "linkFields" ).with(
> > addressField.getClientId(), linkTextField.getClientId() );
> > }
> > } );
> > }
> > }
> >
> >
> >
> > On Mon, Nov 17, 2014 at 10:15 AM, Chris Poulsen <mailingl...@nesluop.dk>
> > wrote:
> >
> >> You are probably asking for trouble if you try to misuse "initializers"
> in
> >> this way (which also explains why two identical init statements results
> in
> >> only one being executed)
> >>
> >> --
> >> Chris
> >>
> >> On Mon, Nov 17, 2014 at 8:45 AM, Charlouze <m...@charlouze.com> wrote:
> >>
> >>> Geoff,
> >>>
> >>> AFAIK, JavascriptSupport is only available at render time and ajax
> render
> >>> doesn't start until after your event handler returns something. I think
> >>> it's because tapestry doesn't know what will need to be rendered yet.
> >>>
> >>> For your second question, I think you can achieve what you want if you
> >>> pass
> >>> arguments to your invoke :
> >>>
> >>> javaScriptSupport.require("components/MyTimer").invoke("
> >>> showTimer").with(true);
> >>>
> >>> It may be a nasty workaround but it works ;)
> >>>
> >>> Charles.
> >>>
> >>> 2014-11-17 7:48 GMT+01:00 Geoff Callender <
> >>> geoff.callender.jumpst...@gmail.com>:
> >>>
> >>>> Chris, It looks like the "rule of thumb" that I stated was wrong. I've
> >>>> just used JavaScriptSupport#require in some AJAX event handlers.
> >>>>
> >>>> Can someone explain under what circumstances we have to use
> >>>> AjaxResponseRenderer#addCallback instead of JavaScriptSupport#require
> ?
> >>>>
> >>>> Is it something to do with queueing requests? For example I noticed a
> >>>> limitation of using require. This...
> >>>>
> >>>>
> >>>> javaScriptSupport.require("components/MyTimer").invoke("showTimer");
> >>>>
> >>>> javaScriptSupport.require("components/MyTimer").invoke("hideTimer");
> >>>>
> >>>> javaScriptSupport.require("components/MyTimer").invoke("showTimer");
> >>>>
> >>>> ...resulted in only 2 invocations in the response to the client...
> >>>>
> >>>> {
> >>>> "_tapestry" : {
> >>>> "inits" : [
> >>>> "components/MyTimer:showTimer",
> >>>> "components/MyTimer:hideTimer"
> >>>> ]
> >>>> }
> >>>> }
> >>>>
> >>>> Geoff
> >>>>
> >>>>
> >>>> On 14 Nov 2014, at 3:23 pm, Geoff Callender <
> >>>> geoff.callender.jumpst...@gmail.com> wrote:
> >>>>
> >>>>> I don't think so. I believe the rule of thumb is to use
> >>>> JavaScriptSupport during render, and use an AJAX callback during
> partial
> >>>> page render.
> >>>>>
> >>>>> IIRC, the JavaScriptSupport environmental is not available when
> you're
> >>>> handling an AJAX component event request.
> >>>>>
> >>>>> On 13 Nov 2014, at 6:08 pm, Chris Poulsen <mailingl...@nesluop.dk>
> >>>> wrote:
> >>>>>
> >>>>>> can't you just use javascriptsupport to require and invoke your js
> >>>> module
> >>>>>> function?
> >>>>>>
> >>>>>> --
> >>>>>> Chris
> >>>>>>
> >>>>>> On Thu, Nov 13, 2014 at 6:34 AM, Geoff Callender <
> >>>>>> geoff.callender.jumpst...@gmail.com> wrote:
> >>>>>>
> >>>>>>> Have you had a look at these two:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>>
> http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/modal/1
> >>>>>>>
> >>>>>>>
> >>>>
> >>>
> http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/reusablemodal/1
> >>>>>>>
> >>>>>>> Do they fit your scenario?
> >>>>>>>
> >>>>>>> On 13 Nov 2014, at 3:40 pm, Paul Stanton <pa...@mapshed.com.au>
> >>> wrote:
> >>>>>>>
> >>>>>>>> Hi Geoff,
> >>>>>>>>
> >>>>>>>> I have found your examples invaluable in learning some of the
> >>> basics
> >>>> of
> >>>>>>> this (and other) concepts. I can't thank you enough
> >>>>>>>>
> >>>>>>>> .. the only thing I can see is missing currently is the example I
> >>>> asked
> >>>>>>> about in the previous mail:
> >>>>>>>>
> >>>>>>>> Basically, how do I interact with a js module instance after it is
> >>>>>>> created?
> >>>>>>>>
> >>>>>>>> pretend some server-side state changes between afterRender and
> >>>>>>> onSomeEvent, and the client needs to react accordingly.
> >>>>>>>>
> >>>>>>>> jss.addScript is deprecated, so I "shouldn't" be telling the
> >>> client to
> >>>>>>> execute script apparently...
> >>>>>>>>
> >>>>>>>> cheers, p.
> >>>>>>>>
> >>>>>>>> On 13/11/2014 2:36 PM, Geoff Callender wrote:
> >>>>>>>>> do these examples cover the situations you are describing?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
