Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of purdrew@gmail.com designates
 209.85.214.47 as permitted sender)
Received-SPF: pass (google.com: domain of purdrew@gmail.com designates
 10.204.10.91 as permitted sender) client-ip=10.204.10.91;
MIME-Version: 1.0
Sender: purdrew@gmail.com
In-Reply-To: 
 <CACAoQH1_M0jf=gFbROxTjU1AT6LAjzUa+ZDXbmRr5_tx9A4SiQ@mail.gmail.com>
References: 
 <CACAoQH1_M0jf=gFbROxTjU1AT6LAjzUa+ZDXbmRr5_tx9A4SiQ@mail.gmail.com>
From: Drew Walters <deedubbu@gmail.com>
Date: Fri, 24 Feb 2012 09:39:46 -0600
Message-ID: 
 <CAO_65gwZfUgL9Fq=uoAJ_4Tve5vSYQvrSk9ow-i_25=Qg9RK-A@mail.gmail.com>
Subject: Re: proposed common-js file moves/renames for post-1.5
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> - 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, a=
nd
> 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. =A0It's not real obviou=
s
> from looking at the files, or the resulting output. =A0Looking at the
> packager.js script gives you the recipe, but it's nice to see the whole
> thing laid out. =A0Which I couldn't see.
>
> I instrumented packager.js to dump the module names and original file nam=
es
> of the source. =A0The result is here:
>
>
> https://github.com/pmuellr/incubator-cordova-js/wiki/cordova-js-file-to-m=
odule-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 t=
he
> .js files, here:
>
>
> https://github.com/pmuellr/incubator-cordova-js/wiki/cordova-js-file-loca=
tion-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. =A0All
> 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, a=
nd
> 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. =A0And would likely simplif=
y
> packager.js. =A0Would also easily allow you to 'overlay' a platform-speci=
fic
> 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. =A0In 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. =A0It's a step in the direction of "all our plugi=
ns
> are just like any other plugins". =A0Due 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. =A0Thought I=
'd
> go ahead and start playing with it, see how it feels. =A0Anyone 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