cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: <plugins> tag, and accessing the plugin list
Date Thu, 14 Nov 2013 20:29:01 GMT
There's a bit of a BC issue here because cordova.js needs to know what file
to inject a <script> tag for, so it can load the file and then load its
module. That's why I hesitated to modify the format of that file,
originally. (It currently sets module.exports to an array of <js-module>
info.) Like Andrew says, entirely possible to make the change, just that
some care is required.

Braden


On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:

> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> > I'm going to attempt to summarize in point form:
> >
> > Goal:
> >  - Make available the list of installed plugins and their versions to
> native side & JS
> > side.
> >  - Needed by App Harness to know whether an app is compatible with its
> > bundled set of plugins.
> >
> > Using cordova_plugins.js:
> >  - It doesn't have the information that we need
> >  - We could add the extra information, but not easily since the file
> exports an
> > array instead of an object.
> >  - This file is not currently parsed by the native layer, so having the
> info here
> > would be an extra IO on start-up.
> >
>
> Great summary :)
>
> Is it difficult to rename ' cordova_plugins.js' to something more broad
> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an
> object?
> Since it's generated code, first impression is there's no BC issue other
> than doing another prepare.
>
> Doesn't seem like there's a way to avoid the extra IO on the native side
> (e.g. cordova_meta.js). If the detailed list of installed plugins is in
> xml, how will the JS side access it?
>
> Broader problem is there's no single cordova meta file that's shared
> between native & js. Considering that on some platforms, there's only
> JavaScript, putting the information in JSON seems like a good move.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message