You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Patrick Mueller <pm...@gmail.com> on 2012/03/19 16:30:35 UTC
CB-280 - Improve layout of cordova-js scripts
It seems like now would be a good time to tackle
https://issues.apache.org/jira/browse/CB-280 . Everyone still generally in
favor of this? The main idea is to just move the files around a bit so the
file 'paths' correspond more closely to the actual module id's, so you
don't have to guess. Also, moves all the platform-specific code to a
platform-specific subdirectory, so all the platform-specific code isn't
sprayed all over the 'lib' directory. I anticipate having to make no code
changes, other than to the build, which should end up being simplified, in
some ways.
Everyone still in favor?
This would be fairly disruptive if folks are making large modifications to
incubator-cordova-js . Anyone in midst of, or planning big changes of any
kind in that project?
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Brian LeRoux <b...@brian.io>.
This is all really good stuff --- we should update the README with the
thinking in this thread.
On Thu, Mar 22, 2012 at 8:42 AM, Drew Walters <de...@gmail.com> wrote:
>> I would agree that we don't folks overriding a lot of the common stuff, but
>> it's nice to have a safety valve. The safety valve is now testable,
>> because I'm shipping exec.js and platform.js in common, which throw errors.
>> So these files are EXPECTED to be overridden. For Smalltalkers, this is
>> "self subclassResponsibility" all over again (codifying that something is
>> meant to be overrriden).
>
> Cool.
>
>> Overriding exec.js is the way to do this, right? In fact, the 'test' and
>> 'errgen' platforms already do this today. Or am I missing something?
>
> In essence, yes. Playbook essentially does this though not in a
> modular way. We need to come up with a common way of doing this
> modularly. Beginning discussions were here:
>
> http://markmail.org/search/?q=proxy+exec&q=list%3Aorg.apache.incubator.callback-dev#query:proxy%20exec%20list%3Aorg.apache.incubator.callback-dev+page:1+mid:p4v5bvri77qtbkpm+state:results
>
>> I don't think the previous packager.js had any special magic foo to do
>> these merges, so I don't think anything has changed in this regard. Or
>> maybe I'm misunderstanding. Can you point me to the place in the old
>> packager.js where "merges" are happening:
>
> It probably could/should be done by packager but right now this is
> done at runtime. The bootstrap file handles the merges
> (platform.merges) at initialization.
>
> https://github.com/apache/incubator-cordova-js/blob/master/lib/bootstrap.js
>
> At any rate, I was misinterpreting what the build process would do. I
> thought the build was copying modules from the platform specific sub
> directory (lib/blackberry/plugin/blackberry/*) to the common plugin
> directory. I now see that it is copying from the platforms plugin
> directory (lib/blackberry/plugin/*).
>
> So, in summary, ignore me, looks good.
>
> On Thu, Mar 22, 2012 at 10:06 AM, Patrick Mueller <pm...@gmail.com> wrote:
>> On Thu, Mar 22, 2012 at 09:48, Drew Walters <de...@gmail.com> wrote:
>>
>>> 'platform specific' files overwrite any 'common' files,
>>> per the order of the cp commands above.
>>>
>>> This makes sense though we need to strive for platforms not overriding
>>> 'common' files since that negates the benefit of cordova-js common
>>> API.
>>>
>>
>> I would agree that we don't folks overriding a lot of the common stuff, but
>> it's nice to have a safety valve. The safety valve is now testable,
>> because I'm shipping exec.js and platform.js in common, which throw errors.
>> So these files are EXPECTED to be overridden. For Smalltalkers, this is
>> "self subclassResponsibility" all over again (codifying that something is
>> meant to be overrriden).
>>
>>
>>> We do however need to provide mechanisms for the following:
>>> ...3. Platforms need to be able to proxy exec to a javascript
>>
>> implementation as opposed to native. This feature does not yet exist,
>>> so platforms are using the "merges" object which overrides existing
>>> API definition.
>>>
>>
>> Overriding exec.js is the way to do this, right? In fact, the 'test' and
>> 'errgen' platforms already do this today. Or am I missing something?
>>
>>
>>> The reason I am mentioning the above is that if we refactored the code
>>> as shown in your commit, then we need to rename files currently using
>>> the "merges" approach as they would override common when they are
>>> intended to augment common.
>>>
>>
>> I don't think the previous packager.js had any special magic foo to do
>> these merges, so I don't think anything has changed in this regard. Or
>> maybe I'm misunderstanding. Can you point me to the place in the old
>> packager.js where "merges" are happening:
>>
>>
>> https://github.com/apache/incubator-cordova-js/blob/master/build/packager.js
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Drew Walters <de...@gmail.com>.
> I would agree that we don't folks overriding a lot of the common stuff, but
> it's nice to have a safety valve. The safety valve is now testable,
> because I'm shipping exec.js and platform.js in common, which throw errors.
> So these files are EXPECTED to be overridden. For Smalltalkers, this is
> "self subclassResponsibility" all over again (codifying that something is
> meant to be overrriden).
Cool.
> Overriding exec.js is the way to do this, right? In fact, the 'test' and
> 'errgen' platforms already do this today. Or am I missing something?
In essence, yes. Playbook essentially does this though not in a
modular way. We need to come up with a common way of doing this
modularly. Beginning discussions were here:
http://markmail.org/search/?q=proxy+exec&q=list%3Aorg.apache.incubator.callback-dev#query:proxy%20exec%20list%3Aorg.apache.incubator.callback-dev+page:1+mid:p4v5bvri77qtbkpm+state:results
> I don't think the previous packager.js had any special magic foo to do
> these merges, so I don't think anything has changed in this regard. Or
> maybe I'm misunderstanding. Can you point me to the place in the old
> packager.js where "merges" are happening:
It probably could/should be done by packager but right now this is
done at runtime. The bootstrap file handles the merges
(platform.merges) at initialization.
https://github.com/apache/incubator-cordova-js/blob/master/lib/bootstrap.js
At any rate, I was misinterpreting what the build process would do. I
thought the build was copying modules from the platform specific sub
directory (lib/blackberry/plugin/blackberry/*) to the common plugin
directory. I now see that it is copying from the platforms plugin
directory (lib/blackberry/plugin/*).
So, in summary, ignore me, looks good.
On Thu, Mar 22, 2012 at 10:06 AM, Patrick Mueller <pm...@gmail.com> wrote:
> On Thu, Mar 22, 2012 at 09:48, Drew Walters <de...@gmail.com> wrote:
>
>> 'platform specific' files overwrite any 'common' files,
>> per the order of the cp commands above.
>>
>> This makes sense though we need to strive for platforms not overriding
>> 'common' files since that negates the benefit of cordova-js common
>> API.
>>
>
> I would agree that we don't folks overriding a lot of the common stuff, but
> it's nice to have a safety valve. The safety valve is now testable,
> because I'm shipping exec.js and platform.js in common, which throw errors.
> So these files are EXPECTED to be overridden. For Smalltalkers, this is
> "self subclassResponsibility" all over again (codifying that something is
> meant to be overrriden).
>
>
>> We do however need to provide mechanisms for the following:
>> ...3. Platforms need to be able to proxy exec to a javascript
>
> implementation as opposed to native. This feature does not yet exist,
>> so platforms are using the "merges" object which overrides existing
>> API definition.
>>
>
> Overriding exec.js is the way to do this, right? In fact, the 'test' and
> 'errgen' platforms already do this today. Or am I missing something?
>
>
>> The reason I am mentioning the above is that if we refactored the code
>> as shown in your commit, then we need to rename files currently using
>> the "merges" approach as they would override common when they are
>> intended to augment common.
>>
>
> I don't think the previous packager.js had any special magic foo to do
> these merges, so I don't think anything has changed in this regard. Or
> maybe I'm misunderstanding. Can you point me to the place in the old
> packager.js where "merges" are happening:
>
>
> https://github.com/apache/incubator-cordova-js/blob/master/build/packager.js
>
> --
> Patrick Mueller
> http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Patrick Mueller <pm...@gmail.com>.
On Thu, Mar 22, 2012 at 09:48, Drew Walters <de...@gmail.com> wrote:
> 'platform specific' files overwrite any 'common' files,
> per the order of the cp commands above.
>
> This makes sense though we need to strive for platforms not overriding
> 'common' files since that negates the benefit of cordova-js common
> API.
>
I would agree that we don't folks overriding a lot of the common stuff, but
it's nice to have a safety valve. The safety valve is now testable,
because I'm shipping exec.js and platform.js in common, which throw errors.
So these files are EXPECTED to be overridden. For Smalltalkers, this is
"self subclassResponsibility" all over again (codifying that something is
meant to be overrriden).
> We do however need to provide mechanisms for the following:
> ...3. Platforms need to be able to proxy exec to a javascript
implementation as opposed to native. This feature does not yet exist,
> so platforms are using the "merges" object which overrides existing
> API definition.
>
Overriding exec.js is the way to do this, right? In fact, the 'test' and
'errgen' platforms already do this today. Or am I missing something?
> The reason I am mentioning the above is that if we refactored the code
> as shown in your commit, then we need to rename files currently using
> the "merges" approach as they would override common when they are
> intended to augment common.
>
I don't think the previous packager.js had any special magic foo to do
these merges, so I don't think anything has changed in this regard. Or
maybe I'm misunderstanding. Can you point me to the place in the old
packager.js where "merges" are happening:
https://github.com/apache/incubator-cordova-js/blob/master/build/packager.js
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Drew Walters <de...@gmail.com>.
Looking at the '2nd try at file refactoring'. I like this structure
much better then the first try. Regarding the following comment from
the commit:
cp -R lib/common gen/android
cp -R lib/android gen/android
'platform specific' files overwrite any 'common' files,
per the order of the cp commands above.
This makes sense though we need to strive for platforms not overriding
'common' files since that negates the benefit of cordova-js common
API. We do however need to provide mechanisms for the following:
1. Platforms should be able to add new modules not in common. Your
refactor makes this easy.
2. Platforms need to be able to 'enhance' a common module API. In the
short term this is currently accomplished through a platforms "merges"
object. Long term we likely need to rethink this.
3. Platforms need to be able to proxy exec to a javascript
implementation as opposed to native. This feature does not yet exist,
so platforms are using the "merges" object which overrides existing
API definition.
The reason I am mentioning the above is that if we refactored the code
as shown in your commit, then we need to rename files currently using
the "merges" approach as they would override common when they are
intended to augment common.
On Wed, Mar 21, 2012 at 5:26 PM, Patrick Mueller <pm...@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 17:42, Patrick Mueller <pm...@gmail.com> wrote:
>
>> 2) additional flattening of removing 'platform'
>>
>> lib/common
>> lib/android
>> lib/...
>> lib/scripts
>>
>
> I like this. You can try it yourself by running this script in the correct
> directory:
>
> https://gist.github.com/2153576
>
> It's non-destructive - it will add a 'lib2' directory to
> incubator-common-js, with the new split.
>
> It removes the 'cordova noise', and all the files in common and the
> platforms are at the same 'level'.
>
> --
> Patrick Mueller
> http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Gord Tanner <go...@tinyhippos.com>.
I am working on cordova-js for the playbook today. Mostly just testing and
verification but I will be careful to not check anything in.
It sounds like Drew verified that BlackBerry works find and I am doing the
final testing on PlayBook.
On Thu, Mar 22, 2012 at 10:57 AM, Patrick Mueller <pm...@gmail.com> wrote:
> OK, I pushed the changes up to my github clone:
>
> https://github.com/pmuellr/incubator-cordova-js/tree/CB-280/lib
>
> Nice, flat directory trees. The commit comment is below.
>
> Any more sheds to paint? I need to test this on Android and iOS, but think
> it's ready to be committed. I'll need to fetch the latest master, rebase,
> rebuild, and then commit. This will leave anyone with commits outstanding
> with some "directory move" merges to make, so ...
>
> IS ANYONE PLANNING ON COMMITTING TO incubator-cordova-js TODAY???
>
> ===== snip =====
> 2nd try at file refactoring
> So, this time, I moved the 'lib' directory to 'lib0'
> for the time being, and use the script 'build/split-cordova.sh'
> to rebuild a new 'lib' directory.
>
> That directory has the following contents:
>
> lib/android - platform specific
> lib/blackberry - platform specific
> lib/common - common modules
> lib/cordova.js - base cordova module
> lib/errgen - platform specific
> lib/ios - platform specific
> lib/playbook - platform specific
> lib/scripts - platform specific
> lib/test - common scripts (not modules)
> lib/webworks - platform specific
> lib/wp7 - platform specific
>
> All the files in lib/ with the exception of lib/scripts are
> modules, and they're all sitting at the same 'level'. So, to
> build a copy of the source modules for android, you can do
> the following:
>
> cp -R lib/common gen/android
> cp -R lib/android gen/android
>
> 'platform specific' files overwrite any 'common' files,
> per the order of the cp commands above.
> ===== snip =====
>
> --
> Patrick Mueller
> http://muellerware.org
>
--
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Patrick Mueller <pm...@gmail.com>.
OK, I pushed the changes up to my github clone:
https://github.com/pmuellr/incubator-cordova-js/tree/CB-280/lib
Nice, flat directory trees. The commit comment is below.
Any more sheds to paint? I need to test this on Android and iOS, but think
it's ready to be committed. I'll need to fetch the latest master, rebase,
rebuild, and then commit. This will leave anyone with commits outstanding
with some "directory move" merges to make, so ...
IS ANYONE PLANNING ON COMMITTING TO incubator-cordova-js TODAY???
===== snip =====
2nd try at file refactoring
So, this time, I moved the 'lib' directory to 'lib0'
for the time being, and use the script 'build/split-cordova.sh'
to rebuild a new 'lib' directory.
That directory has the following contents:
lib/android - platform specific
lib/blackberry - platform specific
lib/common - common modules
lib/cordova.js - base cordova module
lib/errgen - platform specific
lib/ios - platform specific
lib/playbook - platform specific
lib/scripts - platform specific
lib/test - common scripts (not modules)
lib/webworks - platform specific
lib/wp7 - platform specific
All the files in lib/ with the exception of lib/scripts are
modules, and they're all sitting at the same 'level'. So, to
build a copy of the source modules for android, you can do
the following:
cp -R lib/common gen/android
cp -R lib/android gen/android
'platform specific' files overwrite any 'common' files,
per the order of the cp commands above.
===== snip =====
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Patrick Mueller <pm...@gmail.com>.
On Wed, Mar 21, 2012 at 17:42, Patrick Mueller <pm...@gmail.com> wrote:
> 2) additional flattening of removing 'platform'
>
> lib/common
> lib/android
> lib/...
> lib/scripts
>
I like this. You can try it yourself by running this script in the correct
directory:
https://gist.github.com/2153576
It's non-destructive - it will add a 'lib2' directory to
incubator-common-js, with the new split.
It removes the 'cordova noise', and all the files in common and the
platforms are at the same 'level'.
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Patrick Mueller <pm...@gmail.com>.
On Wed, Mar 21, 2012 at 16:55, Brian LeRoux <b...@brian.io> wrote:
> I don't mind this shed but I'm wondering what the purpose of
> lib-platforms/blackberry/cordova part?
>
> why not just lib-platforms/blackberry/ ??
>
> also, and again just touring around the shed, do we plan to ditch
> lib-platforms for lib/platforms after the merge is complete?
Good questions. I'm not married to the current split, just seemed like the
most consistent way of doing it, once I got around to writing the code.
The reason for the unwieldy "lib-platforms/blackberry/cordova" bit is
that, again, I can look at any file name and see what the actual module is,
by look 'up' the path to the cordova part.
But it seems a bit much.
I think one thing that might make sense is to just drop 'cordova'
everywhere in these trees. One thing I'd like to eventually do is to use
"relative" module id's everywhere, and then in that case, you'd NEVER see a
require() with a 'cordova' in it anyway (except for 'root' require()s), at
least in our own modules.
There's one minor hitch with that, and that is that we have a 'cordova'
module, and then modules like 'cordova/builder'. To make this work today,
the common tree needs a 'cordova' directory, along with a cordova.js
sitting right next to that directory. Slightly weird. Node has a
convention that says: if you're looking for module x/y/z, but can't find
x/y/z.js, look for x/y/z/index.js. If we also adopted this (not difficult
to implement), then we'd move the code in lib-common/cordova.js into
lib-common/cordova/index.js. Then we can cleanly kill all the 'cordova'
directories, because there won't be anything else IN those directories, but
the cordova subdirectory.
So, some thoughts, assuming removal of the 'cordova' directories, given the
current
lib-common/
lib-platforms/
lib-platforms/android/
lib-platforms/...
lib-scripts/
1) flatten to /lib:
lib/common
lib/platform/
lib/platform/android
lib/platform/...
lib/scripts
2) additional flattening of removing 'platform'
lib/common
lib/android
lib/...
lib/scripts
*****
2) seems like the best to me, as flat as we can get, but has one issue, in
that our 'special' names (currently just 'common' and 'scripts') are in the
same 'namespace' as platforms. Hope noone comes up with an OS called
'common' or 'scripts' :-) Prolly not a big problem.
You can modify the script 'build/split-cordova.sh' to play with how things
are split up.
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Brian LeRoux <b...@brian.io>.
I don't mind this shed but I'm wondering what the purpose of
lib-platforms/blackberry/cordova part?
why not just lib-platforms/blackberry/ ??
also, and again just touring around the shed, do we plan to ditch
lib-platforms for lib/platforms after the merge is complete?
On Wed, Mar 21, 2012 at 12:18 PM, Patrick Mueller <pm...@gmail.com> wrote:
> OK, I have a 'preview' version of the restructuring available in branch
> CB-280 at both apache [1] and my fork of the apache repo at Github [2].
>
> I think the thing everyone will want to look at is the new directory
> structure, which is really all the CB-280 bug [3] is about - use Github to
> look at it. It's "deeper" than the old structure, but less "bushy", I
> suppose. The nice thing about it is, you can look at any files' name,
> which I often do in text editors, etc, and realize what the module id is
> for that file - the path up to the cordova directory.
>
> The packager could be made a little cleaner by moving the stray
> "require('cordova')" call into bootstrap, but I specifically did not want
> to make any plugin changes with this fix. There's also those 'stray'
> bootstrap-<platform>.js files that can be cleaned up, but I left a little
> hack in there to handle them for now.
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=log;h=refs/heads/CB-280
> [2] https://github.com/pmuellr/incubator-cordova-js/tree/CB-280
> [3] https://issues.apache.org/jira/browse/CB-280
>
> --
> Patrick Mueller
> http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Patrick Mueller <pm...@gmail.com>.
OK, I have a 'preview' version of the restructuring available in branch
CB-280 at both apache [1] and my fork of the apache repo at Github [2].
I think the thing everyone will want to look at is the new directory
structure, which is really all the CB-280 bug [3] is about - use Github to
look at it. It's "deeper" than the old structure, but less "bushy", I
suppose. The nice thing about it is, you can look at any files' name,
which I often do in text editors, etc, and realize what the module id is
for that file - the path up to the cordova directory.
The packager could be made a little cleaner by moving the stray
"require('cordova')" call into bootstrap, but I specifically did not want
to make any plugin changes with this fix. There's also those 'stray'
bootstrap-<platform>.js files that can be cleaned up, but I left a little
hack in there to handle them for now.
[1]
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=log;h=refs/heads/CB-280
[2] https://github.com/pmuellr/incubator-cordova-js/tree/CB-280
[3] https://issues.apache.org/jira/browse/CB-280
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 19, 2012 at 14:31, Filip Maj <fi...@adobe.com> wrote:
> These are two use cases I see so far in the various cordova JS platform
> implementations for module overriding:
>
> 1. I want to completely override a common module. This seems solved with
> the proposed convention of /platform/<platform>/foo.js overriding
> /cordova/foo.js at build time, instead of the current "objects" property
> on the platform definition JSON file.
>
+1
> 2. I want to override or add a few methods on the common foo module (or
> its prototype) with some platform specific stuff. BlackBerry and iOS do a
> fair bit of this. Current suggested method is using the "merges" property
> on the platform definition JSON file. No proposed solution to this in the
> new re-architect? Interestingly most platforms can settle for overriding
> the prototype methods if the parent object to override has a prototype.
> Some platforms, like iOS, however, do NOT allow native code prototype
> overriding so we clobber a specific instance's methods instead. I.e:
>
> navigator.geolocation.getCurrentPosition = require('ios-specific geo
> plugin').getCurrentPosition;
>
The CB-280 issue is really just about moving existing files around. Very
disruptive, and a huge change (kind of), but not touching any API.
Hopefully. Makes for a "as clean as possible" commit. I'd prefer to not
make code changes to the modules, unless we absolutely have to.
> I guess this new approach would also eliminate the need to have an
> explicit common platform definition, as that should just be all of the
> scripts located under the /cordova directory. That being said, the current
> implementation has a few of what Pat calls "scripts" that are defined/used
> as modules: the channel, utils, builder and base cordova scripts are all
> wrapped as modules and used as such throughout the plugin JS files. The
> current path -> module id mapping for these scripts (where applicable) is:
>
> /lib/cordova.js is "cordova"
> /lib/channel.js is "cordova/channel"
> /lib/require.js is in-lined as a script that scopes to the entire built
> cordova.js file
> /lib/bootstrap.js is in-lined
> /lib/builder.js is "cordova/builder"
> /lib/utils.js is "cordova/utils"
>
I was thinking of moving bootstrap and require somewhere by themselves,
since they aren't modules.
> What about the location of the exec module for each platform? Assume the
> existence of an exec.js in each platform/<platform>/ directory?
>
yes
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Filip Maj <fi...@adobe.com>.
These are two use cases I see so far in the various cordova JS platform
implementations for module overriding:
1. I want to completely override a common module. This seems solved with
the proposed convention of /platform/<platform>/foo.js overriding
/cordova/foo.js at build time, instead of the current "objects" property
on the platform definition JSON file.
2. I want to override or add a few methods on the common foo module (or
its prototype) with some platform specific stuff. BlackBerry and iOS do a
fair bit of this. Current suggested method is using the "merges" property
on the platform definition JSON file. No proposed solution to this in the
new re-architect? Interestingly most platforms can settle for overriding
the prototype methods if the parent object to override has a prototype.
Some platforms, like iOS, however, do NOT allow native code prototype
overriding so we clobber a specific instance's methods instead. I.e:
navigator.geolocation.getCurrentPosition = require('ios-specific geo
plugin').getCurrentPosition;
I guess this new approach would also eliminate the need to have an
explicit common platform definition, as that should just be all of the
scripts located under the /cordova directory. That being said, the current
implementation has a few of what Pat calls "scripts" that are defined/used
as modules: the channel, utils, builder and base cordova scripts are all
wrapped as modules and used as such throughout the plugin JS files. The
current path -> module id mapping for these scripts (where applicable) is:
/lib/cordova.js is "cordova"
/lib/channel.js is "cordova/channel"
/lib/require.js is in-lined as a script that scopes to the entire built
cordova.js file
/lib/bootstrap.js is in-lined
/lib/builder.js is "cordova/builder"
/lib/utils.js is "cordova/utils"
What about the location of the exec module for each platform? Assume the
existence of an exec.js in each platform/<platform>/ directory?
On 3/19/12 9:17 AM, "Patrick Mueller" <pm...@gmail.com> wrote:
>On Mon, Mar 19, 2012 at 11:46, Patrick Mueller <pm...@gmail.com> wrote:
>
>> On Mon, Mar 19, 2012 at 11:37, Gord Tanner <go...@tinyhippos.com> wrote:
>>
>>> +1
>>>
>>> If we could somehow lay things out that we can handled more of the
>>> platform
>>> specific insertions and scripts in a convention over configuration
>>>basis
>>> that would be a huge win.
>>>
>>> If I have foo.js in the main folder and a blackberry/foo.js. I would
>>> expect it would overwrite the foo.js during blackberry's build and only
>>> include the platform specific one in the compiled source.
>>
>>
>> Yup. Again, kinda crude, as this is simple to do for single files, may
>> get more complicated if you want to do something like 'delete common
>>thing,
>> don't replace it with anything', or dealing with subdirectories. We can
>> defer those potential complications until we hit them.
>>
>
>Well, dang it, I already have a use case for this 'delete the common
>thing,
>don't replace it with anything' requirement.
>
> https://issues.apache.org/jira/browse/CB-348
>
>It turns out that today, this is just an iOS issue, today, near as I can
>tell. What if we have other platforms that need this later (or even
>today!)?
>
>I suppose, for now, we can just copy the ios console.js (or whatever it
>ends up being called) into each platform that needs it, but ... that's
>obviously a little problematic. To some extent, it would be nice to have
>a
>'portable' console.js in a common place, and then let each platform decide
>whether or not to include it at all. Platforms that didn't want it (all
>but iOS?) could have an empty 'console.js' module in their platform dir,
>but that seems dumb.
>
>Almost seems like the best thing is some kind of configuration (ah
>gr*&()*&) where you'd say, for iOS, "here's an additional module I want
>you
>to add". And then, we'd need a new directory tree of these 'portable, but
>not used by everyone' modules.
>
>--
>Patrick Mueller
>http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 19, 2012 at 11:46, Patrick Mueller <pm...@gmail.com> wrote:
> On Mon, Mar 19, 2012 at 11:37, Gord Tanner <go...@tinyhippos.com> wrote:
>
>> +1
>>
>> If we could somehow lay things out that we can handled more of the
>> platform
>> specific insertions and scripts in a convention over configuration basis
>> that would be a huge win.
>>
>> If I have foo.js in the main folder and a blackberry/foo.js. I would
>> expect it would overwrite the foo.js during blackberry's build and only
>> include the platform specific one in the compiled source.
>
>
> Yup. Again, kinda crude, as this is simple to do for single files, may
> get more complicated if you want to do something like 'delete common thing,
> don't replace it with anything', or dealing with subdirectories. We can
> defer those potential complications until we hit them.
>
Well, dang it, I already have a use case for this 'delete the common thing,
don't replace it with anything' requirement.
https://issues.apache.org/jira/browse/CB-348
It turns out that today, this is just an iOS issue, today, near as I can
tell. What if we have other platforms that need this later (or even
today!)?
I suppose, for now, we can just copy the ios console.js (or whatever it
ends up being called) into each platform that needs it, but ... that's
obviously a little problematic. To some extent, it would be nice to have a
'portable' console.js in a common place, and then let each platform decide
whether or not to include it at all. Platforms that didn't want it (all
but iOS?) could have an empty 'console.js' module in their platform dir,
but that seems dumb.
Almost seems like the best thing is some kind of configuration (ah
gr*&()*&) where you'd say, for iOS, "here's an additional module I want you
to add". And then, we'd need a new directory tree of these 'portable, but
not used by everyone' modules.
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 19, 2012 at 11:37, Gord Tanner <go...@tinyhippos.com> wrote:
> +1
>
> If we could somehow lay things out that we can handled more of the platform
> specific insertions and scripts in a convention over configuration basis
> that would be a huge win.
>
> If I have foo.js in the main folder and a blackberry/foo.js. I would
> expect it would overwrite the foo.js during blackberry's build and only
> include the platform specific one in the compiled source.
Yup. Again, kinda crude, as this is simple to do for single files, may get
more complicated if you want to do something like 'delete common thing,
don't replace it with anything', or dealing with subdirectories. We can
defer those potential complications until we hit them.
--
Patrick Mueller
http://muellerware.org
Re: CB-280 - Improve layout of cordova-js scripts
Posted by Gord Tanner <go...@tinyhippos.com>.
+1
If we could somehow lay things out that we can handled more of the platform
specific insertions and scripts in a convention over configuration basis
that would be a huge win.
If I have foo.js in the main folder and a blackberry/foo.js. I would
expect it would overwrite the foo.js during blackberry's build and only
include the platform specific one in the compiled source.
On Mon, Mar 19, 2012 at 11:30 AM, Patrick Mueller <pm...@gmail.com> wrote:
> It seems like now would be a good time to tackle
> https://issues.apache.org/jira/browse/CB-280 . Everyone still generally
> in
> favor of this? The main idea is to just move the files around a bit so the
> file 'paths' correspond more closely to the actual module id's, so you
> don't have to guess. Also, moves all the platform-specific code to a
> platform-specific subdirectory, so all the platform-specific code isn't
> sprayed all over the 'lib' directory. I anticipate having to make no code
> changes, other than to the build, which should end up being simplified, in
> some ways.
>
> Everyone still in favor?
>
> This would be fairly disruptive if folks are making large modifications to
> incubator-cordova-js . Anyone in midst of, or planning big changes of any
> kind in that project?
>
> --
> Patrick Mueller
> http://muellerware.org
>
--
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos