incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <deedu...@gmail.com>
Subject Re: proposed common-js file moves/renames for post-1.5
Date Fri, 24 Feb 2012 15:39:46 GMT
> - rename `lib` to `cordova`, since that's the top level module bit in our
> modules
+1

> - move the platform-specific modules out of `lib`, into a new top-level
> directory named `platform`, which has subdirectories for each platform, and
> then cordova/blah/... directories for any additional files for the
> platform, including potentially overlaid files
I don't understand why this would be a peer of `lib` and not a child.
In your examples you list 'platform/android/cordova/exec.js'. This
seems to imply that the platform specific files could apply to more
then just cordova since cordova would be a child.  Unless there is a
reason for this, I still like 'cordova/platform/android/exec' better.
Seems to me we would want to keep the module namespace beneath
'cordova'.

> - there are also plain ol' scripts like `require.js` which should be
> separate from the modules, in say a top-level `scripts` directory
+1 though I think require.js is the only example of this so far and I
would vote for keeping it under 'cordova' name space and in a 'lib'
folder (showing my C roots).

> I would also really like to create a subdirectory-per-plugin in the
> `plugins` directory
+1 As we more closely tie native plugin code to JS API from a
packaging standpoint I think this needs to be done for manageability.

On your wiki entry, the following example for 'moving platform files
to separate directories' seems excessive:
    platform/android/cordova/plugin/android/app

Based on my comments above I still like this better:
    cordova/platform/android/plugin/app

Just my thoughts.

On Thu, Feb 23, 2012 at 10:07 PM, Patrick Mueller <pmuellr@gmail.com> wrote:
> I finally got a chance to start looking at the common-js bits this week.
>
> One thing that's had me confused, is figuring out how all the files get
> combined into the platform-specific single files.  It's not real obvious
> from looking at the files, or the resulting output.  Looking at the
> packager.js script gives you the recipe, but it's nice to see the whole
> thing laid out.  Which I couldn't see.
>
> I instrumented packager.js to dump the module names and original file names
> of the source.  The result is here:
>
>
> https://github.com/pmuellr/incubator-cordova-js/wiki/cordova-js-file-to-module-map
>
> (neat that you can enabled a wiki on your cloned GitHub repos!)
>
> On the left is the module id, the right is the original file name.
>
> Based on that, came up with a few thoughts on a clearer organization of the
> .js files, here:
>
>
> https://github.com/pmuellr/incubator-cordova-js/wiki/cordova-js-file-location-refactoring
>
> It seems to me like we should be able to do a little re-org of the files,
> with changes to packager.js, to make things a little more obvious.  All
> without changing any of the actual code - just the file names/directories,
> and packager.js
>
> Changes:
>
> - rename `lib` to `cordova`, since that's the top level module bit in our
> modules
>
> - move the platform-specific modules out of `lib`, into a new top-level
> directory named `platform`, which has subdirectories for each platform, and
> then cordova/blah/... directories for any additional files for the
> platform, including potentially overlaid files
>
> - there are also plain ol' scripts like `require.js` which should be
> separate from the modules, in say a top-level `scripts` directory
>
> All that would, I think, be a little clearer.  And would likely simplify
> packager.js.  Would also easily allow you to 'overlay' a platform-specific
> file over a common one, if you wanted.
>
> If we had a 'portable' version of `cordova/exec.js` and
> `cordova/platform.js`, that existed in the portable directory but was
> always overwritten by platform builds, then the `cordova` directory could
> actually be the source for a "mock" version of Cordova - that you could
> load in a desktop browser, say.  In theory, it would be easy to ingest this
> kind of directory structure in an AMD environment as well.
>
> I would also really like to create a subdirectory-per-plugin in the
> `plugins` directory, but this will affect other code, since those modules
> names will be changing.  It's a step in the direction of "all our plugins
> are just like any other plugins".  Due to the code changes required,
> wouldn't be including this in the first refactor.
>
> I was thinking this might be something we could do post-1.5.  Thought I'd
> go ahead and start playing with it, see how it feels.  Anyone have
> thoughts, or know of any reason why this wouldn't work, or be more
> confusing than the current layout?
>
> --
> Patrick Mueller
> http://muellerware.org

Mime
View raw message