incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: [Cordova-JS] Platform-specific plugin directory structure
Date Wed, 18 Apr 2012 18:57:59 GMT
Thanks for this discussion Fil!
We can leave it the way it is as long as we document it (in the README.rd /
Adding a New Platform). I wasted too much time yesterday trying to figure
out why my plugins weren't loaded and executed :-)

On Tue, Apr 17, 2012 at 7:29 PM, Patrick Mueller <pmuellr@gmail.com> wrote:

> On Tue, Apr 17, 2012 at 20:14, Filip Maj <fil@adobe.com> wrote:
>
> > Ahh, so if I update all of the module string Ids and axe the extra
> > <platform> directory - we are all good, ya? Was wondering if there was
> > specific reasoning other than "this is how we did it before".
> >
>
> I read "update all of the module string ids" as "change the module ids used
> in require() invocations" and "axe the extra <platform> directory" as "mv
> {platform}/plugin/{platform}/* {platform}/plugin" then things will still
> work, assuming the module id's you change in require() match the new module
> names.
>
> However ...
>
> There's something to be said for having the platform name in the module id.
>  I happen to like it.  It's not required, of course, but I like it.  It
> would certainly be possible to change the build to reshape the story so
> there weren't "duplicate" platform names in the file path, but still was a
> platform name in the module id, for instance.
>
> I don't care enough about this, either way, though, to work on any
> alternative approaches.
>
> The other thing to think about is - what happens when we have a 3rd party
> plugin story.  Presumably you would "package" your plugin modules in a
> single wad, somehow separating out platform-specific files.  It's seems
> like a reasonable possibility that the module ids might contain the
> platform name, and that might be a significant part of how the plugin is
> structured.  Or, of course, maybe it won't.  We don't know.
>
> From that aspect, the effort to rejigger all this stuff seems like a waste
> of time, to me.
>
> --
> Patrick Mueller
> http://muellerware.org
>

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