Created a bug for the file moving part (CB-2214), but we can
continue discussing here.
On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve <agri...@chromium.org> wrote:
> Jesse, thanks for the explanation. Certainly my experience is just with
> Android & iOS, so it's good to get opinions from the other platforms.
>
> I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in all
> of the shared plugin modules and hooks them up with the common bootstrap.
> Why do you say that WebOS shares hardly any code?
>
> Blackberry certainly seems to be a bit different in that it looks like it
> is actually 4 platforms in one. Not sure why we don't just make it four
> separate platforms. Gord?
> That said, Blackberry uses the module system even more than other
> platforms. I think it would be a lot of work to make plugin within
> blackberry have it's own loading logic that selectively loads module based
> on the sub-platform (if we went with a single-file pre-built approach).
>
> With the single-file prebuilt approach, I'd guess it would look something
> like this:
>
> plugin.xml says which .js file to include for the platform:
>
> <platform name="android">
> <source-file src="filetransfer.js" />
> </platform>
>
>
> There is certainly a bug-report advantage to having each in its own .js
> file. If everything is in cordova.js, and we get bugs with "Error on line
> ##", we can't actually map that to a file. On the other hand, each platform
> has bootstrap logic that must come after plugins are loaded. This might
> turn into a source of errors if we have a bunch of .js files being added
> via <script> tags.
>
>
> One aspect of plugin JS that I don't want to lose, is our separate pass of
> module -> symbol (defaults/merges/clobbers). In fact, I think this is an
> area that we may wish to enhance in the future. E.g. a couple of releases
> ago we added the ability to print a deprecation message when old namespaces
> are referenced. Other advantages of the system:
> - Helps authors write modules side-effect free modules
> - Allows us to detect symbol collisions
> - Gives us control over when the modules are loaded
> - e.g. We could add measurement to see how long this process takes
> - e.g. We could experiment with lazy-loaded modules by using JS
> getters that return require(module)
> - e.g. We could use this to support exposing Cordova APIs to iframes
>
>
> It might be possible for us to maintain the module->symbol mapping system
> if we had plugins use pre-built .js files. E.g. their .js could be a
> collection of cordova.define() calls, followed by a
> cordova.registerModuleMappings() call. Is that what you're thinking?
>
> In either way, I think I'd like to go ahead with this change of moving
> from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
> this is a good first step for either proposal.
>
>
>
> On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen
> <purplecabb...@gmail.com>wrote:
>
>> Hi Andrew,
>>
>> Having spent some time with this, I don't think it's awful, but I am
>> worried about complexity.
>>
>> To me, a better approach is:
>>
>> - all plugins are simply ripped out of cordova-js
>> - each plugin is distributed 'built' meaning for an API like file or
>> contacts, there is only 1 js file, and while it depends on cordova.js,
>> it is not part of it. ( or possibly just a concat )
>> - plugman does the work of adding/removing but it is really just
>> changing script tags for the js portion
>>
>> This means all our core plugs will need to be modified as the
>> currently depend on the builder to wrap them.
>>
>> I spent some time working with your approach Andrew, and I think it
>> sounds better than it is. Blackberry has 4 inter-related branches to
>> consider, webos shares hardly any code with the other platforms, ... I
>> am more keen on adding consistency than I am to making the tool work
>> around it.
>>
>> If we were only concerned with iOS, Android, and windows phone, then
>> your approach might be best, but there are some messes in there.
>>
>> I will continue to push for the simpler solution, but I won't block
>> you anymore.
>> I do think you should dive a little deeper into your approach, and
>> possibly prove me wrong. I am completely open to further discussion on
>> the point.
>>
>>
>> Cheers,
>> Jesse
>>
>> Sent from my iPhone5
>>
>> On 2013-01-10, at 8:09 PM, Andrew Grieve <agri...@chromium.org> wrote:
>>
>> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gtan...@gmail.com> wrote:
>>
>> > Ideally the require paths should stay true to the following rules (not
>> that
>> > we follow them exactly now but we are close):
>> >
>> > 1. should always start with cordova (in case we ever share a require
>> > framework)
>> > 2. should follow as close as possible to the folder structure.
>> >
>> > We don't really do this now (but we are close). It is mainly to help
>> with
>> > navigation of the project from a require statement:
>> >
>> > var foo = require('cordova/plugin/foo/submodule')
>> >
>> > Ideally I should be able to navigate to a file that lives in:
>> >
>> > ~/cordova.js/plugin/foo/submodule.js
>> >
>> > But realistically we are probably going to see:
>> >
>> > ~/cordova.js/plugin/foo/js/submodule.js
>> >
>> > Assuming we are dumping everything into a js folder here is the
>> "mapping"
>> > off the top of my head:
>> >
>> > var foo = require('cordova/plugin/foo')
>> > ~/cordova.js/plugin/foo/js/index.js
>> >
>> > var foo = require('cordova/plugin/foo/ios')
>> > ~/cordova.js/plugin/foo/js/ios.js
>> >
>> > var foo = require('cordova/plugin/foo/blackberry/qnx')
>> > ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>> >
>> > What does a plugin (native and js code) folder structure look like?
>>
>>
>> Have a look at this plugin: https://github.com/shazron/KeychainPlugin
>>
>> With the JS changes I'm proposing, it would look like:
>> /src/ios/*.h, *.m
>> /www <- empty!
>> /src/js/common/keychain.js
>> or
>> /src/js/ios/keychain.js
>>
>> So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
>> within cordova-js, is that when they move out, there will be the mapping:
>> cordova-js/plugin/$PLUGIN_NAME ---> $PLUGIN_REPO/src/js
>>
>>
>> When a plugin is installed into a project via cordova-cli, I suggest that
>> we get a structure like this:
>>
>> MyApp/platforms/ios/... same as before ...
>> MyApp/cordova-js/... copy of cordova-js
>> MyApp/cordova-js/plugin/keychain/common/keychain.js
>> MyApp/plugins/keychain/plugin.xml
>> MyApp/www
>>
>> So, the idea here is that the cordova-js will have no top-level plugin/
>> directory, but one will be added when plugins are added.
>>
>> Also, like other sources, .js file should be listed in the plugin.xml so
>> that they can be reliably removed.
>>
>>
>>
>> About the require paths. I think for files in cordova-js, the prefix
>> should
>> be "cordova/", but for plugin files, it should be "plugin/" (or maybe
>> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
>> cordova modules.
>>
>> For the keychain example: require('cordovaplugin/keychain/keychain')
>>
>>
>> In terms of changes to the builder, we'd need to add the idea of multiple
>> roots. Instead of just 'lib', there will also be 'plugin' as a root.
>>
>>
>>
>>
>> >
>> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <agri...@google.com>
>> wrote:
>> >
>> >> I'd like to take a first step towards moving plugin JS into separate
>> > repos
>> >> by first moving them around within cordova-js.
>> >>
>> >> Here is my proposal:
>> >>
>> >> Current structure:
>> >> lib/common/plugin/*.js
>> >> lib/$PLATFORM/plugin/*.js
>> >>
>> >> New structure:
>> >> plugin/$PLUGIN_NAME/js/common/*.js
>> >> plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>> >>
>> >> The require path will need to change. Going from:
>> >> cordova.require('cordova/plugin/FileTransferError')
>> >> To:
>> >> cordova.require('plugin/file/FileTransferError')
>> >>
>> >>
>> >> I'll obviously need to update the builder scripts accordingly. The idea
>> >> here is that we:
>> >> 1. "cordova plugin add" will copy files into a project's plugins
>> >> directory
>> >> 2. "cordova build ios" will use the cordova-js packager and pass
>> > it
>> >> the plugin/ directory to use
>> >>
>> >> This will not involve changing how we export modules onto namespaces in
>> >> common.js / platform.js. That will come next though.
>> >>
>> >>
>> >> The resulting structure will look like:
>> >>
>> >> plugin/accelerometer/js/common/Acceleration.js
>> >> plugin/accelerometer/js/common/accelerometer.js
>> >> plugin/battery/js/common/battery.js
>> >> plugin/compass/js/common/Compass*.js
>> >> plugin/contacts/js/common/Contact*.js
>> >> plugin/device/js/common/device.js
>> >> plugin/geolocation/js/common/Coordinates.js
>> >> plugin/geolocation/js/common/Position*.js
>> >> plugin/globalization/js/common/Globalization*.js
>> >> plugin/inappbrowser/js/common/InAppBrowser.js
>> >> plugin/logger/js/common/logger.js
>> >> plugin/logger/js/common/console-via-logger.js
>> >> plugin/media/js/common/Capture*.js
>> >> plugin/media/js/common/ConfigurationData.js
>> >> plugin/media/js/common/Media*.js
>> >> plugin/network/js/common/Connection.js
>> >> plugin/notification/js/common/notification.js
>> >> plugin/camera/js/common/Camera*.js
>> >> plugin/echo/js/common/echo.js
>> >> plugin/file/js/common/Directory*.js
>> >> plugin/file/js/common/Entry.js
>> >> plugin/file/js/common/File*.js
>> >> plugin/file/js/common/Flags.js
>> >> plugin/file/js/common/LocalFileSystem.js
>> >> plugin/file/js/common/Metadata.js
>> >> plugin/file/js/common/ProgressEvent.js
>> >> plugin/splashscreen/js/common/splashscreen.js
>> >
>>
>
>
