You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by J Prince <pr...@hotmail.co.uk> on 2013/06/15 18:16:15 UTC
Suggestion - pluginLoader
In my project I wanted to dynamically load plugin modules (with require.js).
However the current suggested module definition (https://github.com/phonegap/phonegap-plugins/wiki/Defining-Your-Cordova-Plugin-As-A-Cordova-Module) does not suit this approach.
I would like to suggest an alternative approach that would be cleaner and more flexible.
I have written this up, as it features several (untested) code examples.
Please have a look and let me know your thoughts.
https://github.com/jxp/cordova.pluginLoader
Jonathan
Re: Suggestion - pluginLoader
Posted by Filip Maj <fi...@adobe.com>.
+1 on the nice proposal.
I have a fork of the BarcodeScanner plugin [1] that uses the plugin spec
and is plugman-compatible. Right at the top of its plugin.xml you can see
it defines the global for the barcodescanner JS as `window.barcodescanner`.
Also, the cordova team is working on breaking out all of the core APIs
into plugins themselves, and all of these core apis/plugins will be
compatible with plugman. Many of them already work with plugman and the
3.0.0 branches of cordova platforms (which have no APIs other than the
exec bridge). Check out the git-wip repos, anything named cordova-plugin-*
[2].
[1] https://github.com/filmaj/BarcodeScanner/blob/master/plugin.xml
[2] https://git-wip-us.apache.org/repos/asf
On 6/21/13 9:21 AM, "J Prince" <pr...@hotmail.co.uk> wrote:
>That looks much more like what I need.
>I think there were two things adding to my confusion;
>
>1. I was not aware plugman could affect the javascript
>2. I don't think I've seen any clean plugman plugins "in the wild"
>
>I will look into the plugin spec a bit further and do some testing with
>it to see what can be done.
>
>
>
>> From: agrieve@chromium.org
>> Date: Fri, 21 Jun 2013 11:28:28 -0400
>> Subject: Re: Suggestion - pluginLoader
>> To: dev@cordova.apache.org
>>
>> aha, so previously we didn't help plugins along at all.
>>
>> With plugman-compatible plugins, we do define a way for plugin JS to be
>> loaded: you add a <js-module> tag to your plugin.xml and then plugman
>>will
>> wrap your file in a cordova.define().
>>
>> Spec:
>>https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md
>>
>> You can also specify a <runs/> tag in <js-module> which just causes your
>> .js file to be executed after cordova.js is parsed.
>>
>> I think with this, you could layer on another module loading system if
>>you
>> wanted something outside of the cordova.define() system.
>>
>> Does that make sense?
>>
>>
>>
>>
>> On Fri, Jun 21, 2013 at 10:41 AM, J Prince
>><pr...@hotmail.co.uk>wrote:
>>
>> > Perhaps my terminology is wrong but ALL plugins define how they are
>>loaded.
>> >
>> > Either (old style) window.plugins = ...
>> > or (new style) cordova.define(...
>> >
>> > My fundamental point is they shouldn't. I don't want my plugins
>>loaded in
>> > either of these ways. The loading of plugins should be separate to the
>> > plugin definition.
>> > Hence my suggestion of;
>> >
>> > cordova.pluginLoader(...)
>> >
>> > In this pattern pluginLoader could either have multiple different
>>modes or
>> > developers could override it (or both).
>> > At the moment I am having to change each plugin to not define its
>>loading
>> > implementation.
>> >
>> >
>> > > From: agrieve@chromium.org
>> > > Date: Fri, 21 Jun 2013 10:22:35 -0400
>> > > Subject: Re: Suggestion - pluginLoader
>> > > To: dev@cordova.apache.org
>> > >
>> > > For your actual app, you're free to use any JS loader that you'd
>>like.
>> > >
>> > > Are there really many existing Cordova plugins that use alternate
>>module
>> > > package definitions?
>> > >
>> > >
>> > > On Fri, Jun 21, 2013 at 9:39 AM, J Prince
>><princej.ws01@hotmail.co.uk
>> > >wrote:
>> > >
>> > > > Hi Andrew,
>> > > >
>> > > > My main point was to make the actual plugin javascript
>>definitions more
>> > > > flexible.
>> > > > That way it would support more unusual developer requirements
>>(such as
>> > > > mine).
>> > > > If the plugin definitions did not contain any loader
>>implementation
>> > then
>> > > > the same definition can be used different ways by different
>>developers.
>> > > >
>> > > > Currently any existing plugins that I want to use I am making my
>>own
>> > copy
>> > > > of and modifying to suit my project.
>> > > > I found this annoying and produced my suggestion based on that
>> > experience.
>> > > >
>> > > > I suppose it is as much for developer simplicity as anything else.
>> > > > A format that supported different use cases would be better for
>>me!
>> > > > It would also mean that the cordova team could more easily change
>>the
>> > > > javascript plugin loader in future without breaking existing
>>plugins.
>> > > >
>> > > > I hadn't thought about dynamically loading the native side of
>>plugins.
>> > > > I was just assuming that would always be loaded.
>> > > >
>> > > >
>> > > > > From: agrieve@chromium.org
>> > > > > Date: Fri, 21 Jun 2013 09:12:42 -0400
>> > > > > Subject: Re: Suggestion - pluginLoader
>> > > > > To: dev@cordova.apache.org
>> > > > >
>> > > > > Hi Jonathan,
>> > > > >
>> > > > > First, thanks for a well-written proposal. At least for me, I'm
>>not
>> > > > really
>> > > > > sure that there is enough of a problem with the current
>>approach that
>> > > > would
>> > > > > justify changing it. That said, business is always an issue, and
>> > bumping
>> > > > > your thread was the right thing to do :)
>> > > > >
>> > > > > For Android and iOS, the large majority of plugins require
>>native
>> > code in
>> > > > > order to be useful, so I don't think that having plugin JS be
>> > dynamically
>> > > > > seems that useful without being able to dynamically load the
>>native
>> > parts
>> > > > > of it.
>> > > > >
>> > > > > You said that you're serving your app via HTTP. I think your
>>best bet
>> > > > would
>> > > > > be to concat all of your plugin JS together would be by far your
>> > biggest
>> > > > > performance boost rather than try to selectively load them.
>> > > > >
>> > > > > Until very recently, Cordova's module system didn't involve a
>>loader
>> > at
>> > > > > all, and required that all modules be defined ahead of time.
>>Now, we
>> > > > > actually do load plugin .js files during start-up, but still not
>> > > > on-demand.
>> > > > > So, in my mind we really have two things:
>> > > > > 1. A registry
>> > > > > 2. A boot-up process.
>> > > > >
>> > > > > To be clear - is it that you want to change the registry part,
>>or is
>> > it
>> > > > > just that you want to have plugin .js loaded on-demand? Are you
>> > concerned
>> > > > > about the native side of the plugins?
>> > > > >
>> > > > > One thing I think maybe we should add is the ability to disable
>>the
>> > > > > start-up plugin_loader.js logic for when people want to package
>>the
>> > .js
>> > > > > themselves.
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Fri, Jun 21, 2013 at 8:30 AM, J Prince <
>> > princej.ws01@hotmail.co.uk
>> > > > >wrote:
>> > > > >
>> > > > > > So it's been about a week now and I haven't really had any
>> > feedback on
>> > > > > > this.
>> > > > > > https://github.com/jxp/cordova.pluginLoader
>> > > > > > I'm not sure if this means;
>> > > > > >
>> > > > > > a) Everyone is too busy
>> > > > > > b) Everyone assumed someone else would respond
>> > > > > > c) No-one is that interested in plugin javascript definitions
>> > > > > > d) You've had similar discussions before and don't want to
>>start
>> > THAT
>> > > > again
>> > > > > >
>> > > > > >
>> > > > > > > From: princej.ws01@hotmail.co.uk
>> > > > > > > To: dev@cordova.apache.org
>> > > > > > > Subject: RE: Suggestion - pluginLoader
>> > > > > > > Date: Tue, 18 Jun 2013 16:55:19 +0100
>> > > > > > >
>> > > > > > > I have (briefly) looked at Harmony loaders before but that
>>is a
>> > spec
>> > > > for
>> > > > > > a future javascript language version.
>> > > > > > > I have found a module loader that I wish to use
>>(require.js).
>> > > > > > >
>> > > > > > > My point is that the current suggested module definition for
>> > cordova
>> > > > > > plugins INCLUDES a loader implementation.
>> > > > > > >
>> > > > > > > I am suggesting that the loader implementation be removed
>>from
>> > the
>> > > > > > plugin to a new method cordova.pluginLoader
>> > > > > > > This would make the plugins cleaner (as they would only
>>describe
>> > > > their
>> > > > > > own behaviour) and it would also allow cordova or app
>>developers to
>> > > > > > change/customize the loader implementation as needed.
>> > > > > > >
>> > > > > > > My suggested approach would result in plugins that could be
>> > loaded in
>> > > > > > multiple different ways including (but not limited to);
>>"classic"
>> > > > > > window.plugins, cordova.define and require.js
>> > > > > > >
>> > > > > > >
>> > > > > > > > -----Original Message-----
>> > > > > > > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
>> > > > > > > > Sent: Monday, June 17, 2013 7:27 AM
>> > > > > > > > To: dev@cordova.apache.org
>> > > > > > > > Subject: RE: Suggestion - pluginLoader
>> > > > > > > >
>> > > > > > > > There are a few main reasons.
>> > > > > > > >
>> > > > > > > > 1. The app I am working on is an Enterprise app. We are
>> > designing
>> > > > the
>> > > > > > app as a Cordova shell that re-directs to all the html
>>content.
>> > This
>> > > > means
>> > > > > > that we have to dynamically load a different cordova.js
>>(depending
>> > on
>> > > > > > platform) following the redirect.
>> > > > > > > > So we are actually unable to do anything other than
>>dynamically
>> > > > load
>> > > > > > plugins once the platform specific cordova.js is loaded
>> > > > > > > >
>> > > > > > > > 2. Some of the plugins will be used incredibly rarely. It
>> > doesn't
>> > > > seem
>> > > > > > necessary to always load plugins until they are needed.
>> > > > > > > >
>> > > > > > > > 3. We are building with a single page architecture so
>>don't
>> > want to
>> > > > > > end up with lots of script includes in the index.html page.
>> > > > > > > > The define/require pattern feels much cleaner and better
>> > > > > > compartmentalized.
>> > > > > > > > Our main page currently has 2 script includes: require.js
>>and
>> > > > jqmobi.
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > >
>> > > >
>> >
>> >
>
RE: Suggestion - pluginLoader
Posted by J Prince <pr...@hotmail.co.uk>.
That looks much more like what I need.
I think there were two things adding to my confusion;
1. I was not aware plugman could affect the javascript
2. I don't think I've seen any clean plugman plugins "in the wild"
I will look into the plugin spec a bit further and do some testing with it to see what can be done.
> From: agrieve@chromium.org
> Date: Fri, 21 Jun 2013 11:28:28 -0400
> Subject: Re: Suggestion - pluginLoader
> To: dev@cordova.apache.org
>
> aha, so previously we didn't help plugins along at all.
>
> With plugman-compatible plugins, we do define a way for plugin JS to be
> loaded: you add a <js-module> tag to your plugin.xml and then plugman will
> wrap your file in a cordova.define().
>
> Spec: https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md
>
> You can also specify a <runs/> tag in <js-module> which just causes your
> .js file to be executed after cordova.js is parsed.
>
> I think with this, you could layer on another module loading system if you
> wanted something outside of the cordova.define() system.
>
> Does that make sense?
>
>
>
>
> On Fri, Jun 21, 2013 at 10:41 AM, J Prince <pr...@hotmail.co.uk>wrote:
>
> > Perhaps my terminology is wrong but ALL plugins define how they are loaded.
> >
> > Either (old style) window.plugins = ...
> > or (new style) cordova.define(...
> >
> > My fundamental point is they shouldn't. I don't want my plugins loaded in
> > either of these ways. The loading of plugins should be separate to the
> > plugin definition.
> > Hence my suggestion of;
> >
> > cordova.pluginLoader(...)
> >
> > In this pattern pluginLoader could either have multiple different modes or
> > developers could override it (or both).
> > At the moment I am having to change each plugin to not define its loading
> > implementation.
> >
> >
> > > From: agrieve@chromium.org
> > > Date: Fri, 21 Jun 2013 10:22:35 -0400
> > > Subject: Re: Suggestion - pluginLoader
> > > To: dev@cordova.apache.org
> > >
> > > For your actual app, you're free to use any JS loader that you'd like.
> > >
> > > Are there really many existing Cordova plugins that use alternate module
> > > package definitions?
> > >
> > >
> > > On Fri, Jun 21, 2013 at 9:39 AM, J Prince <princej.ws01@hotmail.co.uk
> > >wrote:
> > >
> > > > Hi Andrew,
> > > >
> > > > My main point was to make the actual plugin javascript definitions more
> > > > flexible.
> > > > That way it would support more unusual developer requirements (such as
> > > > mine).
> > > > If the plugin definitions did not contain any loader implementation
> > then
> > > > the same definition can be used different ways by different developers.
> > > >
> > > > Currently any existing plugins that I want to use I am making my own
> > copy
> > > > of and modifying to suit my project.
> > > > I found this annoying and produced my suggestion based on that
> > experience.
> > > >
> > > > I suppose it is as much for developer simplicity as anything else.
> > > > A format that supported different use cases would be better for me!
> > > > It would also mean that the cordova team could more easily change the
> > > > javascript plugin loader in future without breaking existing plugins.
> > > >
> > > > I hadn't thought about dynamically loading the native side of plugins.
> > > > I was just assuming that would always be loaded.
> > > >
> > > >
> > > > > From: agrieve@chromium.org
> > > > > Date: Fri, 21 Jun 2013 09:12:42 -0400
> > > > > Subject: Re: Suggestion - pluginLoader
> > > > > To: dev@cordova.apache.org
> > > > >
> > > > > Hi Jonathan,
> > > > >
> > > > > First, thanks for a well-written proposal. At least for me, I'm not
> > > > really
> > > > > sure that there is enough of a problem with the current approach that
> > > > would
> > > > > justify changing it. That said, business is always an issue, and
> > bumping
> > > > > your thread was the right thing to do :)
> > > > >
> > > > > For Android and iOS, the large majority of plugins require native
> > code in
> > > > > order to be useful, so I don't think that having plugin JS be
> > dynamically
> > > > > seems that useful without being able to dynamically load the native
> > parts
> > > > > of it.
> > > > >
> > > > > You said that you're serving your app via HTTP. I think your best bet
> > > > would
> > > > > be to concat all of your plugin JS together would be by far your
> > biggest
> > > > > performance boost rather than try to selectively load them.
> > > > >
> > > > > Until very recently, Cordova's module system didn't involve a loader
> > at
> > > > > all, and required that all modules be defined ahead of time. Now, we
> > > > > actually do load plugin .js files during start-up, but still not
> > > > on-demand.
> > > > > So, in my mind we really have two things:
> > > > > 1. A registry
> > > > > 2. A boot-up process.
> > > > >
> > > > > To be clear - is it that you want to change the registry part, or is
> > it
> > > > > just that you want to have plugin .js loaded on-demand? Are you
> > concerned
> > > > > about the native side of the plugins?
> > > > >
> > > > > One thing I think maybe we should add is the ability to disable the
> > > > > start-up plugin_loader.js logic for when people want to package the
> > .js
> > > > > themselves.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jun 21, 2013 at 8:30 AM, J Prince <
> > princej.ws01@hotmail.co.uk
> > > > >wrote:
> > > > >
> > > > > > So it's been about a week now and I haven't really had any
> > feedback on
> > > > > > this.
> > > > > > https://github.com/jxp/cordova.pluginLoader
> > > > > > I'm not sure if this means;
> > > > > >
> > > > > > a) Everyone is too busy
> > > > > > b) Everyone assumed someone else would respond
> > > > > > c) No-one is that interested in plugin javascript definitions
> > > > > > d) You've had similar discussions before and don't want to start
> > THAT
> > > > again
> > > > > >
> > > > > >
> > > > > > > From: princej.ws01@hotmail.co.uk
> > > > > > > To: dev@cordova.apache.org
> > > > > > > Subject: RE: Suggestion - pluginLoader
> > > > > > > Date: Tue, 18 Jun 2013 16:55:19 +0100
> > > > > > >
> > > > > > > I have (briefly) looked at Harmony loaders before but that is a
> > spec
> > > > for
> > > > > > a future javascript language version.
> > > > > > > I have found a module loader that I wish to use (require.js).
> > > > > > >
> > > > > > > My point is that the current suggested module definition for
> > cordova
> > > > > > plugins INCLUDES a loader implementation.
> > > > > > >
> > > > > > > I am suggesting that the loader implementation be removed from
> > the
> > > > > > plugin to a new method cordova.pluginLoader
> > > > > > > This would make the plugins cleaner (as they would only describe
> > > > their
> > > > > > own behaviour) and it would also allow cordova or app developers to
> > > > > > change/customize the loader implementation as needed.
> > > > > > >
> > > > > > > My suggested approach would result in plugins that could be
> > loaded in
> > > > > > multiple different ways including (but not limited to); "classic"
> > > > > > window.plugins, cordova.define and require.js
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> > > > > > > > Sent: Monday, June 17, 2013 7:27 AM
> > > > > > > > To: dev@cordova.apache.org
> > > > > > > > Subject: RE: Suggestion - pluginLoader
> > > > > > > >
> > > > > > > > There are a few main reasons.
> > > > > > > >
> > > > > > > > 1. The app I am working on is an Enterprise app. We are
> > designing
> > > > the
> > > > > > app as a Cordova shell that re-directs to all the html content.
> > This
> > > > means
> > > > > > that we have to dynamically load a different cordova.js (depending
> > on
> > > > > > platform) following the redirect.
> > > > > > > > So we are actually unable to do anything other than dynamically
> > > > load
> > > > > > plugins once the platform specific cordova.js is loaded
> > > > > > > >
> > > > > > > > 2. Some of the plugins will be used incredibly rarely. It
> > doesn't
> > > > seem
> > > > > > necessary to always load plugins until they are needed.
> > > > > > > >
> > > > > > > > 3. We are building with a single page architecture so don't
> > want to
> > > > > > end up with lots of script includes in the index.html page.
> > > > > > > > The define/require pattern feels much cleaner and better
> > > > > > compartmentalized.
> > > > > > > > Our main page currently has 2 script includes: require.js and
> > > > jqmobi.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
Re: Suggestion - pluginLoader
Posted by Andrew Grieve <ag...@chromium.org>.
aha, so previously we didn't help plugins along at all.
With plugman-compatible plugins, we do define a way for plugin JS to be
loaded: you add a <js-module> tag to your plugin.xml and then plugman will
wrap your file in a cordova.define().
Spec: https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md
You can also specify a <runs/> tag in <js-module> which just causes your
.js file to be executed after cordova.js is parsed.
I think with this, you could layer on another module loading system if you
wanted something outside of the cordova.define() system.
Does that make sense?
On Fri, Jun 21, 2013 at 10:41 AM, J Prince <pr...@hotmail.co.uk>wrote:
> Perhaps my terminology is wrong but ALL plugins define how they are loaded.
>
> Either (old style) window.plugins = ...
> or (new style) cordova.define(...
>
> My fundamental point is they shouldn't. I don't want my plugins loaded in
> either of these ways. The loading of plugins should be separate to the
> plugin definition.
> Hence my suggestion of;
>
> cordova.pluginLoader(...)
>
> In this pattern pluginLoader could either have multiple different modes or
> developers could override it (or both).
> At the moment I am having to change each plugin to not define its loading
> implementation.
>
>
> > From: agrieve@chromium.org
> > Date: Fri, 21 Jun 2013 10:22:35 -0400
> > Subject: Re: Suggestion - pluginLoader
> > To: dev@cordova.apache.org
> >
> > For your actual app, you're free to use any JS loader that you'd like.
> >
> > Are there really many existing Cordova plugins that use alternate module
> > package definitions?
> >
> >
> > On Fri, Jun 21, 2013 at 9:39 AM, J Prince <princej.ws01@hotmail.co.uk
> >wrote:
> >
> > > Hi Andrew,
> > >
> > > My main point was to make the actual plugin javascript definitions more
> > > flexible.
> > > That way it would support more unusual developer requirements (such as
> > > mine).
> > > If the plugin definitions did not contain any loader implementation
> then
> > > the same definition can be used different ways by different developers.
> > >
> > > Currently any existing plugins that I want to use I am making my own
> copy
> > > of and modifying to suit my project.
> > > I found this annoying and produced my suggestion based on that
> experience.
> > >
> > > I suppose it is as much for developer simplicity as anything else.
> > > A format that supported different use cases would be better for me!
> > > It would also mean that the cordova team could more easily change the
> > > javascript plugin loader in future without breaking existing plugins.
> > >
> > > I hadn't thought about dynamically loading the native side of plugins.
> > > I was just assuming that would always be loaded.
> > >
> > >
> > > > From: agrieve@chromium.org
> > > > Date: Fri, 21 Jun 2013 09:12:42 -0400
> > > > Subject: Re: Suggestion - pluginLoader
> > > > To: dev@cordova.apache.org
> > > >
> > > > Hi Jonathan,
> > > >
> > > > First, thanks for a well-written proposal. At least for me, I'm not
> > > really
> > > > sure that there is enough of a problem with the current approach that
> > > would
> > > > justify changing it. That said, business is always an issue, and
> bumping
> > > > your thread was the right thing to do :)
> > > >
> > > > For Android and iOS, the large majority of plugins require native
> code in
> > > > order to be useful, so I don't think that having plugin JS be
> dynamically
> > > > seems that useful without being able to dynamically load the native
> parts
> > > > of it.
> > > >
> > > > You said that you're serving your app via HTTP. I think your best bet
> > > would
> > > > be to concat all of your plugin JS together would be by far your
> biggest
> > > > performance boost rather than try to selectively load them.
> > > >
> > > > Until very recently, Cordova's module system didn't involve a loader
> at
> > > > all, and required that all modules be defined ahead of time. Now, we
> > > > actually do load plugin .js files during start-up, but still not
> > > on-demand.
> > > > So, in my mind we really have two things:
> > > > 1. A registry
> > > > 2. A boot-up process.
> > > >
> > > > To be clear - is it that you want to change the registry part, or is
> it
> > > > just that you want to have plugin .js loaded on-demand? Are you
> concerned
> > > > about the native side of the plugins?
> > > >
> > > > One thing I think maybe we should add is the ability to disable the
> > > > start-up plugin_loader.js logic for when people want to package the
> .js
> > > > themselves.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Jun 21, 2013 at 8:30 AM, J Prince <
> princej.ws01@hotmail.co.uk
> > > >wrote:
> > > >
> > > > > So it's been about a week now and I haven't really had any
> feedback on
> > > > > this.
> > > > > https://github.com/jxp/cordova.pluginLoader
> > > > > I'm not sure if this means;
> > > > >
> > > > > a) Everyone is too busy
> > > > > b) Everyone assumed someone else would respond
> > > > > c) No-one is that interested in plugin javascript definitions
> > > > > d) You've had similar discussions before and don't want to start
> THAT
> > > again
> > > > >
> > > > >
> > > > > > From: princej.ws01@hotmail.co.uk
> > > > > > To: dev@cordova.apache.org
> > > > > > Subject: RE: Suggestion - pluginLoader
> > > > > > Date: Tue, 18 Jun 2013 16:55:19 +0100
> > > > > >
> > > > > > I have (briefly) looked at Harmony loaders before but that is a
> spec
> > > for
> > > > > a future javascript language version.
> > > > > > I have found a module loader that I wish to use (require.js).
> > > > > >
> > > > > > My point is that the current suggested module definition for
> cordova
> > > > > plugins INCLUDES a loader implementation.
> > > > > >
> > > > > > I am suggesting that the loader implementation be removed from
> the
> > > > > plugin to a new method cordova.pluginLoader
> > > > > > This would make the plugins cleaner (as they would only describe
> > > their
> > > > > own behaviour) and it would also allow cordova or app developers to
> > > > > change/customize the loader implementation as needed.
> > > > > >
> > > > > > My suggested approach would result in plugins that could be
> loaded in
> > > > > multiple different ways including (but not limited to); "classic"
> > > > > window.plugins, cordova.define and require.js
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> > > > > > > Sent: Monday, June 17, 2013 7:27 AM
> > > > > > > To: dev@cordova.apache.org
> > > > > > > Subject: RE: Suggestion - pluginLoader
> > > > > > >
> > > > > > > There are a few main reasons.
> > > > > > >
> > > > > > > 1. The app I am working on is an Enterprise app. We are
> designing
> > > the
> > > > > app as a Cordova shell that re-directs to all the html content.
> This
> > > means
> > > > > that we have to dynamically load a different cordova.js (depending
> on
> > > > > platform) following the redirect.
> > > > > > > So we are actually unable to do anything other than dynamically
> > > load
> > > > > plugins once the platform specific cordova.js is loaded
> > > > > > >
> > > > > > > 2. Some of the plugins will be used incredibly rarely. It
> doesn't
> > > seem
> > > > > necessary to always load plugins until they are needed.
> > > > > > >
> > > > > > > 3. We are building with a single page architecture so don't
> want to
> > > > > end up with lots of script includes in the index.html page.
> > > > > > > The define/require pattern feels much cleaner and better
> > > > > compartmentalized.
> > > > > > > Our main page currently has 2 script includes: require.js and
> > > jqmobi.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > >
> > >
>
>
RE: Suggestion - pluginLoader
Posted by J Prince <pr...@hotmail.co.uk>.
Perhaps my terminology is wrong but ALL plugins define how they are loaded.
Either (old style) window.plugins = ...
or (new style) cordova.define(...
My fundamental point is they shouldn't. I don't want my plugins loaded in either of these ways. The loading of plugins should be separate to the plugin definition.
Hence my suggestion of;
cordova.pluginLoader(...)
In this pattern pluginLoader could either have multiple different modes or developers could override it (or both).
At the moment I am having to change each plugin to not define its loading implementation.
> From: agrieve@chromium.org
> Date: Fri, 21 Jun 2013 10:22:35 -0400
> Subject: Re: Suggestion - pluginLoader
> To: dev@cordova.apache.org
>
> For your actual app, you're free to use any JS loader that you'd like.
>
> Are there really many existing Cordova plugins that use alternate module
> package definitions?
>
>
> On Fri, Jun 21, 2013 at 9:39 AM, J Prince <pr...@hotmail.co.uk>wrote:
>
> > Hi Andrew,
> >
> > My main point was to make the actual plugin javascript definitions more
> > flexible.
> > That way it would support more unusual developer requirements (such as
> > mine).
> > If the plugin definitions did not contain any loader implementation then
> > the same definition can be used different ways by different developers.
> >
> > Currently any existing plugins that I want to use I am making my own copy
> > of and modifying to suit my project.
> > I found this annoying and produced my suggestion based on that experience.
> >
> > I suppose it is as much for developer simplicity as anything else.
> > A format that supported different use cases would be better for me!
> > It would also mean that the cordova team could more easily change the
> > javascript plugin loader in future without breaking existing plugins.
> >
> > I hadn't thought about dynamically loading the native side of plugins.
> > I was just assuming that would always be loaded.
> >
> >
> > > From: agrieve@chromium.org
> > > Date: Fri, 21 Jun 2013 09:12:42 -0400
> > > Subject: Re: Suggestion - pluginLoader
> > > To: dev@cordova.apache.org
> > >
> > > Hi Jonathan,
> > >
> > > First, thanks for a well-written proposal. At least for me, I'm not
> > really
> > > sure that there is enough of a problem with the current approach that
> > would
> > > justify changing it. That said, business is always an issue, and bumping
> > > your thread was the right thing to do :)
> > >
> > > For Android and iOS, the large majority of plugins require native code in
> > > order to be useful, so I don't think that having plugin JS be dynamically
> > > seems that useful without being able to dynamically load the native parts
> > > of it.
> > >
> > > You said that you're serving your app via HTTP. I think your best bet
> > would
> > > be to concat all of your plugin JS together would be by far your biggest
> > > performance boost rather than try to selectively load them.
> > >
> > > Until very recently, Cordova's module system didn't involve a loader at
> > > all, and required that all modules be defined ahead of time. Now, we
> > > actually do load plugin .js files during start-up, but still not
> > on-demand.
> > > So, in my mind we really have two things:
> > > 1. A registry
> > > 2. A boot-up process.
> > >
> > > To be clear - is it that you want to change the registry part, or is it
> > > just that you want to have plugin .js loaded on-demand? Are you concerned
> > > about the native side of the plugins?
> > >
> > > One thing I think maybe we should add is the ability to disable the
> > > start-up plugin_loader.js logic for when people want to package the .js
> > > themselves.
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Jun 21, 2013 at 8:30 AM, J Prince <princej.ws01@hotmail.co.uk
> > >wrote:
> > >
> > > > So it's been about a week now and I haven't really had any feedback on
> > > > this.
> > > > https://github.com/jxp/cordova.pluginLoader
> > > > I'm not sure if this means;
> > > >
> > > > a) Everyone is too busy
> > > > b) Everyone assumed someone else would respond
> > > > c) No-one is that interested in plugin javascript definitions
> > > > d) You've had similar discussions before and don't want to start THAT
> > again
> > > >
> > > >
> > > > > From: princej.ws01@hotmail.co.uk
> > > > > To: dev@cordova.apache.org
> > > > > Subject: RE: Suggestion - pluginLoader
> > > > > Date: Tue, 18 Jun 2013 16:55:19 +0100
> > > > >
> > > > > I have (briefly) looked at Harmony loaders before but that is a spec
> > for
> > > > a future javascript language version.
> > > > > I have found a module loader that I wish to use (require.js).
> > > > >
> > > > > My point is that the current suggested module definition for cordova
> > > > plugins INCLUDES a loader implementation.
> > > > >
> > > > > I am suggesting that the loader implementation be removed from the
> > > > plugin to a new method cordova.pluginLoader
> > > > > This would make the plugins cleaner (as they would only describe
> > their
> > > > own behaviour) and it would also allow cordova or app developers to
> > > > change/customize the loader implementation as needed.
> > > > >
> > > > > My suggested approach would result in plugins that could be loaded in
> > > > multiple different ways including (but not limited to); "classic"
> > > > window.plugins, cordova.define and require.js
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> > > > > > Sent: Monday, June 17, 2013 7:27 AM
> > > > > > To: dev@cordova.apache.org
> > > > > > Subject: RE: Suggestion - pluginLoader
> > > > > >
> > > > > > There are a few main reasons.
> > > > > >
> > > > > > 1. The app I am working on is an Enterprise app. We are designing
> > the
> > > > app as a Cordova shell that re-directs to all the html content. This
> > means
> > > > that we have to dynamically load a different cordova.js (depending on
> > > > platform) following the redirect.
> > > > > > So we are actually unable to do anything other than dynamically
> > load
> > > > plugins once the platform specific cordova.js is loaded
> > > > > >
> > > > > > 2. Some of the plugins will be used incredibly rarely. It doesn't
> > seem
> > > > necessary to always load plugins until they are needed.
> > > > > >
> > > > > > 3. We are building with a single page architecture so don't want to
> > > > end up with lots of script includes in the index.html page.
> > > > > > The define/require pattern feels much cleaner and better
> > > > compartmentalized.
> > > > > > Our main page currently has 2 script includes: require.js and
> > jqmobi.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> >
> >
Re: Suggestion - pluginLoader
Posted by Andrew Grieve <ag...@chromium.org>.
For your actual app, you're free to use any JS loader that you'd like.
Are there really many existing Cordova plugins that use alternate module
package definitions?
On Fri, Jun 21, 2013 at 9:39 AM, J Prince <pr...@hotmail.co.uk>wrote:
> Hi Andrew,
>
> My main point was to make the actual plugin javascript definitions more
> flexible.
> That way it would support more unusual developer requirements (such as
> mine).
> If the plugin definitions did not contain any loader implementation then
> the same definition can be used different ways by different developers.
>
> Currently any existing plugins that I want to use I am making my own copy
> of and modifying to suit my project.
> I found this annoying and produced my suggestion based on that experience.
>
> I suppose it is as much for developer simplicity as anything else.
> A format that supported different use cases would be better for me!
> It would also mean that the cordova team could more easily change the
> javascript plugin loader in future without breaking existing plugins.
>
> I hadn't thought about dynamically loading the native side of plugins.
> I was just assuming that would always be loaded.
>
>
> > From: agrieve@chromium.org
> > Date: Fri, 21 Jun 2013 09:12:42 -0400
> > Subject: Re: Suggestion - pluginLoader
> > To: dev@cordova.apache.org
> >
> > Hi Jonathan,
> >
> > First, thanks for a well-written proposal. At least for me, I'm not
> really
> > sure that there is enough of a problem with the current approach that
> would
> > justify changing it. That said, business is always an issue, and bumping
> > your thread was the right thing to do :)
> >
> > For Android and iOS, the large majority of plugins require native code in
> > order to be useful, so I don't think that having plugin JS be dynamically
> > seems that useful without being able to dynamically load the native parts
> > of it.
> >
> > You said that you're serving your app via HTTP. I think your best bet
> would
> > be to concat all of your plugin JS together would be by far your biggest
> > performance boost rather than try to selectively load them.
> >
> > Until very recently, Cordova's module system didn't involve a loader at
> > all, and required that all modules be defined ahead of time. Now, we
> > actually do load plugin .js files during start-up, but still not
> on-demand.
> > So, in my mind we really have two things:
> > 1. A registry
> > 2. A boot-up process.
> >
> > To be clear - is it that you want to change the registry part, or is it
> > just that you want to have plugin .js loaded on-demand? Are you concerned
> > about the native side of the plugins?
> >
> > One thing I think maybe we should add is the ability to disable the
> > start-up plugin_loader.js logic for when people want to package the .js
> > themselves.
> >
> >
> >
> >
> >
> > On Fri, Jun 21, 2013 at 8:30 AM, J Prince <princej.ws01@hotmail.co.uk
> >wrote:
> >
> > > So it's been about a week now and I haven't really had any feedback on
> > > this.
> > > https://github.com/jxp/cordova.pluginLoader
> > > I'm not sure if this means;
> > >
> > > a) Everyone is too busy
> > > b) Everyone assumed someone else would respond
> > > c) No-one is that interested in plugin javascript definitions
> > > d) You've had similar discussions before and don't want to start THAT
> again
> > >
> > >
> > > > From: princej.ws01@hotmail.co.uk
> > > > To: dev@cordova.apache.org
> > > > Subject: RE: Suggestion - pluginLoader
> > > > Date: Tue, 18 Jun 2013 16:55:19 +0100
> > > >
> > > > I have (briefly) looked at Harmony loaders before but that is a spec
> for
> > > a future javascript language version.
> > > > I have found a module loader that I wish to use (require.js).
> > > >
> > > > My point is that the current suggested module definition for cordova
> > > plugins INCLUDES a loader implementation.
> > > >
> > > > I am suggesting that the loader implementation be removed from the
> > > plugin to a new method cordova.pluginLoader
> > > > This would make the plugins cleaner (as they would only describe
> their
> > > own behaviour) and it would also allow cordova or app developers to
> > > change/customize the loader implementation as needed.
> > > >
> > > > My suggested approach would result in plugins that could be loaded in
> > > multiple different ways including (but not limited to); "classic"
> > > window.plugins, cordova.define and require.js
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> > > > > Sent: Monday, June 17, 2013 7:27 AM
> > > > > To: dev@cordova.apache.org
> > > > > Subject: RE: Suggestion - pluginLoader
> > > > >
> > > > > There are a few main reasons.
> > > > >
> > > > > 1. The app I am working on is an Enterprise app. We are designing
> the
> > > app as a Cordova shell that re-directs to all the html content. This
> means
> > > that we have to dynamically load a different cordova.js (depending on
> > > platform) following the redirect.
> > > > > So we are actually unable to do anything other than dynamically
> load
> > > plugins once the platform specific cordova.js is loaded
> > > > >
> > > > > 2. Some of the plugins will be used incredibly rarely. It doesn't
> seem
> > > necessary to always load plugins until they are needed.
> > > > >
> > > > > 3. We are building with a single page architecture so don't want to
> > > end up with lots of script includes in the index.html page.
> > > > > The define/require pattern feels much cleaner and better
> > > compartmentalized.
> > > > > Our main page currently has 2 script includes: require.js and
> jqmobi.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
>
>
RE: Suggestion - pluginLoader
Posted by J Prince <pr...@hotmail.co.uk>.
Hi Andrew,
My main point was to make the actual plugin javascript definitions more flexible.
That way it would support more unusual developer requirements (such as mine).
If the plugin definitions did not contain any loader implementation then the same definition can be used different ways by different developers.
Currently any existing plugins that I want to use I am making my own copy of and modifying to suit my project.
I found this annoying and produced my suggestion based on that experience.
I suppose it is as much for developer simplicity as anything else.
A format that supported different use cases would be better for me!
It would also mean that the cordova team could more easily change the javascript plugin loader in future without breaking existing plugins.
I hadn't thought about dynamically loading the native side of plugins.
I was just assuming that would always be loaded.
> From: agrieve@chromium.org
> Date: Fri, 21 Jun 2013 09:12:42 -0400
> Subject: Re: Suggestion - pluginLoader
> To: dev@cordova.apache.org
>
> Hi Jonathan,
>
> First, thanks for a well-written proposal. At least for me, I'm not really
> sure that there is enough of a problem with the current approach that would
> justify changing it. That said, business is always an issue, and bumping
> your thread was the right thing to do :)
>
> For Android and iOS, the large majority of plugins require native code in
> order to be useful, so I don't think that having plugin JS be dynamically
> seems that useful without being able to dynamically load the native parts
> of it.
>
> You said that you're serving your app via HTTP. I think your best bet would
> be to concat all of your plugin JS together would be by far your biggest
> performance boost rather than try to selectively load them.
>
> Until very recently, Cordova's module system didn't involve a loader at
> all, and required that all modules be defined ahead of time. Now, we
> actually do load plugin .js files during start-up, but still not on-demand.
> So, in my mind we really have two things:
> 1. A registry
> 2. A boot-up process.
>
> To be clear - is it that you want to change the registry part, or is it
> just that you want to have plugin .js loaded on-demand? Are you concerned
> about the native side of the plugins?
>
> One thing I think maybe we should add is the ability to disable the
> start-up plugin_loader.js logic for when people want to package the .js
> themselves.
>
>
>
>
>
> On Fri, Jun 21, 2013 at 8:30 AM, J Prince <pr...@hotmail.co.uk>wrote:
>
> > So it's been about a week now and I haven't really had any feedback on
> > this.
> > https://github.com/jxp/cordova.pluginLoader
> > I'm not sure if this means;
> >
> > a) Everyone is too busy
> > b) Everyone assumed someone else would respond
> > c) No-one is that interested in plugin javascript definitions
> > d) You've had similar discussions before and don't want to start THAT again
> >
> >
> > > From: princej.ws01@hotmail.co.uk
> > > To: dev@cordova.apache.org
> > > Subject: RE: Suggestion - pluginLoader
> > > Date: Tue, 18 Jun 2013 16:55:19 +0100
> > >
> > > I have (briefly) looked at Harmony loaders before but that is a spec for
> > a future javascript language version.
> > > I have found a module loader that I wish to use (require.js).
> > >
> > > My point is that the current suggested module definition for cordova
> > plugins INCLUDES a loader implementation.
> > >
> > > I am suggesting that the loader implementation be removed from the
> > plugin to a new method cordova.pluginLoader
> > > This would make the plugins cleaner (as they would only describe their
> > own behaviour) and it would also allow cordova or app developers to
> > change/customize the loader implementation as needed.
> > >
> > > My suggested approach would result in plugins that could be loaded in
> > multiple different ways including (but not limited to); "classic"
> > window.plugins, cordova.define and require.js
> > >
> > >
> > > > -----Original Message-----
> > > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> > > > Sent: Monday, June 17, 2013 7:27 AM
> > > > To: dev@cordova.apache.org
> > > > Subject: RE: Suggestion - pluginLoader
> > > >
> > > > There are a few main reasons.
> > > >
> > > > 1. The app I am working on is an Enterprise app. We are designing the
> > app as a Cordova shell that re-directs to all the html content. This means
> > that we have to dynamically load a different cordova.js (depending on
> > platform) following the redirect.
> > > > So we are actually unable to do anything other than dynamically load
> > plugins once the platform specific cordova.js is loaded
> > > >
> > > > 2. Some of the plugins will be used incredibly rarely. It doesn't seem
> > necessary to always load plugins until they are needed.
> > > >
> > > > 3. We are building with a single page architecture so don't want to
> > end up with lots of script includes in the index.html page.
> > > > The define/require pattern feels much cleaner and better
> > compartmentalized.
> > > > Our main page currently has 2 script includes: require.js and jqmobi.
> > > >
> > > >
> > > >
> > >
> >
> >
Re: Suggestion - pluginLoader
Posted by Andrew Grieve <ag...@chromium.org>.
Hi Jonathan,
First, thanks for a well-written proposal. At least for me, I'm not really
sure that there is enough of a problem with the current approach that would
justify changing it. That said, business is always an issue, and bumping
your thread was the right thing to do :)
For Android and iOS, the large majority of plugins require native code in
order to be useful, so I don't think that having plugin JS be dynamically
seems that useful without being able to dynamically load the native parts
of it.
You said that you're serving your app via HTTP. I think your best bet would
be to concat all of your plugin JS together would be by far your biggest
performance boost rather than try to selectively load them.
Until very recently, Cordova's module system didn't involve a loader at
all, and required that all modules be defined ahead of time. Now, we
actually do load plugin .js files during start-up, but still not on-demand.
So, in my mind we really have two things:
1. A registry
2. A boot-up process.
To be clear - is it that you want to change the registry part, or is it
just that you want to have plugin .js loaded on-demand? Are you concerned
about the native side of the plugins?
One thing I think maybe we should add is the ability to disable the
start-up plugin_loader.js logic for when people want to package the .js
themselves.
On Fri, Jun 21, 2013 at 8:30 AM, J Prince <pr...@hotmail.co.uk>wrote:
> So it's been about a week now and I haven't really had any feedback on
> this.
> https://github.com/jxp/cordova.pluginLoader
> I'm not sure if this means;
>
> a) Everyone is too busy
> b) Everyone assumed someone else would respond
> c) No-one is that interested in plugin javascript definitions
> d) You've had similar discussions before and don't want to start THAT again
>
>
> > From: princej.ws01@hotmail.co.uk
> > To: dev@cordova.apache.org
> > Subject: RE: Suggestion - pluginLoader
> > Date: Tue, 18 Jun 2013 16:55:19 +0100
> >
> > I have (briefly) looked at Harmony loaders before but that is a spec for
> a future javascript language version.
> > I have found a module loader that I wish to use (require.js).
> >
> > My point is that the current suggested module definition for cordova
> plugins INCLUDES a loader implementation.
> >
> > I am suggesting that the loader implementation be removed from the
> plugin to a new method cordova.pluginLoader
> > This would make the plugins cleaner (as they would only describe their
> own behaviour) and it would also allow cordova or app developers to
> change/customize the loader implementation as needed.
> >
> > My suggested approach would result in plugins that could be loaded in
> multiple different ways including (but not limited to); "classic"
> window.plugins, cordova.define and require.js
> >
> >
> > > -----Original Message-----
> > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> > > Sent: Monday, June 17, 2013 7:27 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Suggestion - pluginLoader
> > >
> > > There are a few main reasons.
> > >
> > > 1. The app I am working on is an Enterprise app. We are designing the
> app as a Cordova shell that re-directs to all the html content. This means
> that we have to dynamically load a different cordova.js (depending on
> platform) following the redirect.
> > > So we are actually unable to do anything other than dynamically load
> plugins once the platform specific cordova.js is loaded
> > >
> > > 2. Some of the plugins will be used incredibly rarely. It doesn't seem
> necessary to always load plugins until they are needed.
> > >
> > > 3. We are building with a single page architecture so don't want to
> end up with lots of script includes in the index.html page.
> > > The define/require pattern feels much cleaner and better
> compartmentalized.
> > > Our main page currently has 2 script includes: require.js and jqmobi.
> > >
> > >
> > >
> >
>
>
RE: Suggestion - pluginLoader
Posted by J Prince <pr...@hotmail.co.uk>.
So it's been about a week now and I haven't really had any feedback on this.
https://github.com/jxp/cordova.pluginLoader
I'm not sure if this means;
a) Everyone is too busy
b) Everyone assumed someone else would respond
c) No-one is that interested in plugin javascript definitions
d) You've had similar discussions before and don't want to start THAT again
> From: princej.ws01@hotmail.co.uk
> To: dev@cordova.apache.org
> Subject: RE: Suggestion - pluginLoader
> Date: Tue, 18 Jun 2013 16:55:19 +0100
>
> I have (briefly) looked at Harmony loaders before but that is a spec for a future javascript language version.
> I have found a module loader that I wish to use (require.js).
>
> My point is that the current suggested module definition for cordova plugins INCLUDES a loader implementation.
>
> I am suggesting that the loader implementation be removed from the plugin to a new method cordova.pluginLoader
> This would make the plugins cleaner (as they would only describe their own behaviour) and it would also allow cordova or app developers to change/customize the loader implementation as needed.
>
> My suggested approach would result in plugins that could be loaded in multiple different ways including (but not limited to); "classic" window.plugins, cordova.define and require.js
>
>
> > -----Original Message-----
> > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> > Sent: Monday, June 17, 2013 7:27 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Suggestion - pluginLoader
> >
> > There are a few main reasons.
> >
> > 1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect.
> > So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded
> >
> > 2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed.
> >
> > 3. We are building with a single page architecture so don't want to end up with lots of script includes in the index.html page.
> > The define/require pattern feels much cleaner and better compartmentalized.
> > Our main page currently has 2 script includes: require.js and jqmobi.
> >
> >
> >
>
RE: Suggestion - pluginLoader
Posted by J Prince <pr...@hotmail.co.uk>.
I have (briefly) looked at Harmony loaders before but that is a spec for a future javascript language version.
I have found a module loader that I wish to use (require.js).
My point is that the current suggested module definition for cordova plugins INCLUDES a loader implementation.
I am suggesting that the loader implementation be removed from the plugin to a new method cordova.pluginLoader
This would make the plugins cleaner (as they would only describe their own behaviour) and it would also allow cordova or app developers to change/customize the loader implementation as needed.
My suggested approach would result in plugins that could be loaded in multiple different ways including (but not limited to); "classic" window.plugins, cordova.define and require.js
> From: jbondc@openmv.com
> To: dev@cordova.apache.org
> Subject: RE: Suggestion - pluginLoader
> Date: Tue, 18 Jun 2013 15:08:27 +0000
>
> Take a look at:
> http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
> https://gist.github.com/wycats/51c96e3adcdb3a68cbc3
>
> That type of extensible loader could make sense in Cordova and seems like it would meet all your requirements.
>
>
> -----Original Message-----
> From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> Sent: Monday, June 17, 2013 7:27 AM
> To: dev@cordova.apache.org
> Subject: RE: Suggestion - pluginLoader
>
> There are a few main reasons.
>
> 1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect.
> So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded
>
> 2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed.
>
> 3. We are building with a single page architecture so don't want to end up with lots of script includes in the index.html page.
> The define/require pattern feels much cleaner and better compartmentalized.
> Our main page currently has 2 script includes: require.js and jqmobi.
>
>
>
RE: Suggestion - pluginLoader
Posted by "jbondc@openmv.com" <jb...@openmv.com>.
Take a look at:
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
https://gist.github.com/wycats/51c96e3adcdb3a68cbc3
That type of extensible loader could make sense in Cordova and seems like it would meet all your requirements.
-----Original Message-----
From: J Prince [mailto:princej.ws01@hotmail.co.uk]
Sent: Monday, June 17, 2013 7:27 AM
To: dev@cordova.apache.org
Subject: RE: Suggestion - pluginLoader
There are a few main reasons.
1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect.
So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded
2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed.
3. We are building with a single page architecture so don't want to end up with lots of script includes in the index.html page.
The define/require pattern feels much cleaner and better compartmentalized.
Our main page currently has 2 script includes: require.js and jqmobi.
RE: Suggestion - pluginLoader
Posted by J Prince <pr...@hotmail.co.uk>.
There are a few main reasons.
1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect.
So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded
2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed.
3. We are building with a single page architecture so don't want to end up with lots of script includes in the index.html page.
The define/require pattern feels much cleaner and better compartmentalized.
Our main page currently has 2 script includes: require.js and jqmobi.
I am already doing something similar to what I proposed in my project. As this is actually a small change and results in a plugin definition that is compatible with the current cordova.define approach, the old window.plugins, and my own use case I thought it would be worth suggesting it to you. I wasn't sure how this might affect any planned changes to plugins so didn't feel it was worth diving in with a pull request.
This is a new feature and would not break any existing plugins. It would also allows developers (or the cordova team in future) to customize/change how they wish plugins to be loaded.
> Date: Mon, 17 Jun 2013 04:05:52 -0700
> Subject: Re: Suggestion - pluginLoader
> From: b@brian.io
> To: dev@cordova.apache.org
>
> Hey Jonathan, looks super interesting. I'd like to better understand
> the motivations / use case. So, can you describe more about why you
> want to dynamically load modules for a plugin?
>
>
Re: Suggestion - pluginLoader
Posted by Brian LeRoux <b...@brian.io>.
Hey Jonathan, looks super interesting. I'd like to better understand
the motivations / use case. So, can you describe more about why you
want to dynamically load modules for a plugin?
On Sat, Jun 15, 2013 at 9:16 AM, J Prince <pr...@hotmail.co.uk> wrote:
> In my project I wanted to dynamically load plugin modules (with require.js).
> However the current suggested module definition (https://github.com/phonegap/phonegap-plugins/wiki/Defining-Your-Cordova-Plugin-As-A-Cordova-Module) does not suit this approach.
>
> I would like to suggest an alternative approach that would be cleaner and more flexible.
>
> I have written this up, as it features several (untested) code examples.
>
> Please have a look and let me know your thoughts.
>
> https://github.com/jxp/cordova.pluginLoader
>
>
> Jonathan
>