> 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 <hls...@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.ey...@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 <steve.ey...@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-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
