You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Steve Eynon <st...@alienfactory.co.uk> on 2013/01/17 06:32:59 UTC
T5.4-alpha-2: Module Initialization Priority / Order
Hiya,
I have the following in a component:
void setupRender() {
jsSupport.require("af/highcharts/theme/darkGreen").priority(InitializationPriority.EARLY);
jsSupport.require("af/highcharts/lineChart").with(params);
}
and yet the theme module is still called *after* the lineChart. From
Firefox console:
Invoking af/highcharts/lineChart({ ... })
Invoking af/highcharts/theme/darkGreen()
Is this because one module is invoked with params and the other
without? The component is used several times on the same page,
resulting in many calls to "require" the same modules.
Steve.
P.S. So far I'm liking the use of RequireJS - I get a cosy feeling
from having my dependencies injected into my JS modules, it's like an
IoC for JS!
--
Steve Eynon
-------------------------------
"If at first you don't succeed,
so much for skydiving!"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.4-alpha-2: Module Initialization Priority / Order
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Fri, Jan 18, 2013 at 11:38 PM, Steve Eynon <
steve.eynon@alienfactory.co.uk> wrote:
> > If possible, change your module to not care about order.
>
> Hmm... that reminds me of:
>
> Patient: "Doctor, doctor! It hurts when I do this"
> Doctor: "Well don't do it then!"
>
> After realising this has to be a common issue with RequireJS, I
> figured it must have been already solved. And in some way it is, via
> the depends / define mechanism:
>
> If module B needs to run after module A, then module B depends on
> module A. If you update your module B definition to:
>
> define ["jquery", "A"], ($) -> # note A is not even given a
> variable declaration
>
>
Yes, and you'll see examples of this in Tapestry's modules.
> then it seems all calls to module A are executed before module B.
>
> Note it doesn't matter what dependencies I declare in my
> JavaScriptModuleConfigurations, the only change that makes a
> difference is in the JS define signature. (Which does lead me to ask
> why I need to declare my dependencies in two different places - in the
> JS and the TapestryModule.)
>
You don't!
>
> While this works well, it is not idea for my use case; which is
> optionally loading skins for a charting framework. Each skin is a
> separate module / file and I make a call to initialise the one being
> used. But because the modules are static files, I now need to depend
> on / and download ALL the skins before initialising the one in use.
>
> I guess I'm after some kind of dynamic / runtime dependency, which is
> what the InitialisationPriority gave me.
>
You could pass in the name of a theme as one of the params to the linechart
module. It could use require() to load the theme.
Yes, some of the mechansisms in Tapestry that date way back are ordered
around a smart server ordering the libraries into correct load order.
There's some adjustment in paradigms when it is a smart client figuring out
the load order dynamically.
>
> > However, I'm thinking about scanning the inits and doing a pre-load pass,
> > where it artifically forces all the dependencies to be loaded before
> > invoking any inits
>
> While that would work, surely you'd loose some of the speed benefits
> of using AMD? As waiting for everything to download first is
> technically not much better than a window.load mechanism.
>
> You could do a pre-load pass for each of the InitialisationPriorites
> (early, norm & late) but then I feel you'd be fighting the RequireJS
> way of things.
>
> I think what is in place is good, only the InitialisationPriority
> should probably be scrapped (it always seemed like a course grained
> cludge to me anyway) and the depends mechanism probably needs a little
> more thought / love.
>
> Steve.
> --
> Steve Eynon
> -------------------------------
> "If at first you don't succeed,
> so much for skydiving!"
>
>
>
> On 19 January 2013 01:51, Howard Lewis Ship <hl...@gmail.com> wrote:
> > Yes, lots of async going on, so the dependencies of the modules may cause
> > the module's exporting function (the thing you pass to define() as the
> > second parameter) to occur in an unpredictable order.
> >
> > If possible, change your module to not care about order.
> >
> > However, I'm thinking about scanning the inits and doing a pre-load pass,
> > where it artifically forces all the dependencies to be loaded before
> > invoking any inits. Still thinking about that ... as in, should it be
> > necessary? Are the modules and logic broken if such a phase is
> necessary?
> >
> > On Fri, Jan 18, 2013 at 12:19 AM, Steve Eynon <
> > steve.eynon@alienfactory.co.uk> wrote:
> >
> >> The priority ordering is lost when the call is handed over to
> >> RequireJS from pageinit:invokeInitializer().
> >>
> >> There's a shed load of code on the server side to ensure the priority
> >> ordering is kept.
> >> The generated page init JSON is in the correct order.
> >> The initialisation code is called in the correct order.
> >> But pageinit:invokeInitializer() doesn't actually invoke the
> >> initializer. It calls require() which seems to store a callback to be
> >> executed sometime later.
> >>
> >> I'm guessing the random execution order is due to the async nature of
> >> the modules being loaded.
> >>
> >> Being new to AMD and RequireJS I don't know how to go about fixing
> >> this. Should I raise a JIRA?
> >>
> >> Steve.
> >> --
> >> Steve Eynon
> >> -------------------------------
> >> "If at first you don't succeed,
> >> so much for skydiving!"
> >>
> >>
> >>
> >> On 17 January 2013 13:32, Steve Eynon <st...@alienfactory.co.uk>
> >> wrote:
> >> > Hiya,
> >> >
> >> > I have the following in a component:
> >> >
> >> > void setupRender() {
> >> >
> >>
> jsSupport.require("af/highcharts/theme/darkGreen").priority(InitializationPriority.EARLY);
> >> > jsSupport.require("af/highcharts/lineChart").with(params);
> >> > }
> >> >
> >> > and yet the theme module is still called *after* the lineChart. From
> >> > Firefox console:
> >> >
> >> > Invoking af/highcharts/lineChart({ ... })
> >> > Invoking af/highcharts/theme/darkGreen()
> >> >
> >> > Is this because one module is invoked with params and the other
> >> > without? The component is used several times on the same page,
> >> > resulting in many calls to "require" the same modules.
> >> >
> >> > Steve.
> >> > P.S. So far I'm liking the use of RequireJS - I get a cosy feeling
> >> > from having my dependencies injected into my JS modules, it's like an
> >> > IoC for JS!
> >> > --
> >> > Steve Eynon
> >> > -------------------------------
> >> > "If at first you don't succeed,
> >> > so much for skydiving!"
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator of Apache Tapestry
> >
> > The source for Tapestry training, mentoring and support. Contact me to
> > learn how I can get you up and productive in Tapestry fast!
> >
> > (971) 678-5210
> > http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: T5.4-alpha-2: Module Initialization Priority / Order
Posted by Steve Eynon <st...@alienfactory.co.uk>.
> If possible, change your module to not care about order.
Hmm... that reminds me of:
Patient: "Doctor, doctor! It hurts when I do this"
Doctor: "Well don't do it then!"
After realising this has to be a common issue with RequireJS, I
figured it must have been already solved. And in some way it is, via
the depends / define mechanism:
If module B needs to run after module A, then module B depends on
module A. If you update your module B definition to:
define ["jquery", "A"], ($) -> # note A is not even given a
variable declaration
then it seems all calls to module A are executed before module B.
Note it doesn't matter what dependencies I declare in my
JavaScriptModuleConfigurations, the only change that makes a
difference is in the JS define signature. (Which does lead me to ask
why I need to declare my dependencies in two different places - in the
JS and the TapestryModule.)
While this works well, it is not idea for my use case; which is
optionally loading skins for a charting framework. Each skin is a
separate module / file and I make a call to initialise the one being
used. But because the modules are static files, I now need to depend
on / and download ALL the skins before initialising the one in use.
I guess I'm after some kind of dynamic / runtime dependency, which is
what the InitialisationPriority gave me.
> However, I'm thinking about scanning the inits and doing a pre-load pass,
> where it artifically forces all the dependencies to be loaded before
> invoking any inits
While that would work, surely you'd loose some of the speed benefits
of using AMD? As waiting for everything to download first is
technically not much better than a window.load mechanism.
You could do a pre-load pass for each of the InitialisationPriorites
(early, norm & late) but then I feel you'd be fighting the RequireJS
way of things.
I think what is in place is good, only the InitialisationPriority
should probably be scrapped (it always seemed like a course grained
cludge to me anyway) and the depends mechanism probably needs a little
more thought / love.
Steve.
--
Steve Eynon
-------------------------------
"If at first you don't succeed,
so much for skydiving!"
On 19 January 2013 01:51, Howard Lewis Ship <hl...@gmail.com> wrote:
> Yes, lots of async going on, so the dependencies of the modules may cause
> the module's exporting function (the thing you pass to define() as the
> second parameter) to occur in an unpredictable order.
>
> If possible, change your module to not care about order.
>
> However, I'm thinking about scanning the inits and doing a pre-load pass,
> where it artifically forces all the dependencies to be loaded before
> invoking any inits. Still thinking about that ... as in, should it be
> necessary? Are the modules and logic broken if such a phase is necessary?
>
> On Fri, Jan 18, 2013 at 12:19 AM, Steve Eynon <
> steve.eynon@alienfactory.co.uk> wrote:
>
>> The priority ordering is lost when the call is handed over to
>> RequireJS from pageinit:invokeInitializer().
>>
>> There's a shed load of code on the server side to ensure the priority
>> ordering is kept.
>> The generated page init JSON is in the correct order.
>> The initialisation code is called in the correct order.
>> But pageinit:invokeInitializer() doesn't actually invoke the
>> initializer. It calls require() which seems to store a callback to be
>> executed sometime later.
>>
>> I'm guessing the random execution order is due to the async nature of
>> the modules being loaded.
>>
>> Being new to AMD and RequireJS I don't know how to go about fixing
>> this. Should I raise a JIRA?
>>
>> Steve.
>> --
>> Steve Eynon
>> -------------------------------
>> "If at first you don't succeed,
>> so much for skydiving!"
>>
>>
>>
>> On 17 January 2013 13:32, Steve Eynon <st...@alienfactory.co.uk>
>> wrote:
>> > Hiya,
>> >
>> > I have the following in a component:
>> >
>> > void setupRender() {
>> >
>> jsSupport.require("af/highcharts/theme/darkGreen").priority(InitializationPriority.EARLY);
>> > jsSupport.require("af/highcharts/lineChart").with(params);
>> > }
>> >
>> > and yet the theme module is still called *after* the lineChart. From
>> > Firefox console:
>> >
>> > Invoking af/highcharts/lineChart({ ... })
>> > Invoking af/highcharts/theme/darkGreen()
>> >
>> > Is this because one module is invoked with params and the other
>> > without? The component is used several times on the same page,
>> > resulting in many calls to "require" the same modules.
>> >
>> > Steve.
>> > P.S. So far I'm liking the use of RequireJS - I get a cosy feeling
>> > from having my dependencies injected into my JS modules, it's like an
>> > IoC for JS!
>> > --
>> > Steve Eynon
>> > -------------------------------
>> > "If at first you don't succeed,
>> > so much for skydiving!"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.4-alpha-2: Module Initialization Priority / Order
Posted by Howard Lewis Ship <hl...@gmail.com>.
Yes, lots of async going on, so the dependencies of the modules may cause
the module's exporting function (the thing you pass to define() as the
second parameter) to occur in an unpredictable order.
If possible, change your module to not care about order.
However, I'm thinking about scanning the inits and doing a pre-load pass,
where it artifically forces all the dependencies to be loaded before
invoking any inits. Still thinking about that ... as in, should it be
necessary? Are the modules and logic broken if such a phase is necessary?
On Fri, Jan 18, 2013 at 12:19 AM, Steve Eynon <
steve.eynon@alienfactory.co.uk> wrote:
> The priority ordering is lost when the call is handed over to
> RequireJS from pageinit:invokeInitializer().
>
> There's a shed load of code on the server side to ensure the priority
> ordering is kept.
> The generated page init JSON is in the correct order.
> The initialisation code is called in the correct order.
> But pageinit:invokeInitializer() doesn't actually invoke the
> initializer. It calls require() which seems to store a callback to be
> executed sometime later.
>
> I'm guessing the random execution order is due to the async nature of
> the modules being loaded.
>
> Being new to AMD and RequireJS I don't know how to go about fixing
> this. Should I raise a JIRA?
>
> Steve.
> --
> Steve Eynon
> -------------------------------
> "If at first you don't succeed,
> so much for skydiving!"
>
>
>
> On 17 January 2013 13:32, Steve Eynon <st...@alienfactory.co.uk>
> wrote:
> > Hiya,
> >
> > I have the following in a component:
> >
> > void setupRender() {
> >
> jsSupport.require("af/highcharts/theme/darkGreen").priority(InitializationPriority.EARLY);
> > jsSupport.require("af/highcharts/lineChart").with(params);
> > }
> >
> > and yet the theme module is still called *after* the lineChart. From
> > Firefox console:
> >
> > Invoking af/highcharts/lineChart({ ... })
> > Invoking af/highcharts/theme/darkGreen()
> >
> > Is this because one module is invoked with params and the other
> > without? The component is used several times on the same page,
> > resulting in many calls to "require" the same modules.
> >
> > Steve.
> > P.S. So far I'm liking the use of RequireJS - I get a cosy feeling
> > from having my dependencies injected into my JS modules, it's like an
> > IoC for JS!
> > --
> > Steve Eynon
> > -------------------------------
> > "If at first you don't succeed,
> > so much for skydiving!"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: T5.4-alpha-2: Module Initialization Priority / Order
Posted by Steve Eynon <st...@alienfactory.co.uk>.
The priority ordering is lost when the call is handed over to
RequireJS from pageinit:invokeInitializer().
There's a shed load of code on the server side to ensure the priority
ordering is kept.
The generated page init JSON is in the correct order.
The initialisation code is called in the correct order.
But pageinit:invokeInitializer() doesn't actually invoke the
initializer. It calls require() which seems to store a callback to be
executed sometime later.
I'm guessing the random execution order is due to the async nature of
the modules being loaded.
Being new to AMD and RequireJS I don't know how to go about fixing
this. Should I raise a JIRA?
Steve.
--
Steve Eynon
-------------------------------
"If at first you don't succeed,
so much for skydiving!"
On 17 January 2013 13:32, Steve Eynon <st...@alienfactory.co.uk> wrote:
> Hiya,
>
> I have the following in a component:
>
> void setupRender() {
> jsSupport.require("af/highcharts/theme/darkGreen").priority(InitializationPriority.EARLY);
> jsSupport.require("af/highcharts/lineChart").with(params);
> }
>
> and yet the theme module is still called *after* the lineChart. From
> Firefox console:
>
> Invoking af/highcharts/lineChart({ ... })
> Invoking af/highcharts/theme/darkGreen()
>
> Is this because one module is invoked with params and the other
> without? The component is used several times on the same page,
> resulting in many calls to "require" the same modules.
>
> Steve.
> P.S. So far I'm liking the use of RequireJS - I get a cosy feeling
> from having my dependencies injected into my JS modules, it's like an
> IoC for JS!
> --
> Steve Eynon
> -------------------------------
> "If at first you don't succeed,
> so much for skydiving!"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org