You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Michael Brooks <mi...@michaelbrooks.ca> on 2013/03/25 22:34:08 UTC
[cordova-cli] Merges Directory
Just like to provide an alternative suggestion to the merges/ directory and
here everyone's thoughts.
While doing client work at Nitobi, each of our build scripts had similar
functionality to merging platform-specific web assets. Below, I'll describe
what I've experienced and make a suggestion on an improvement.
1. Separate Merges Directory
app
|__ merges/
| |__ android/
|__ www/
In the above structure, the android/ directory is a mirror of the www/
directory. When a file exists in the android/ directory, it will replace
the file in the www/.
I believe this is how the merges/ directory in `cordova-cli` works.
I've experienced two main problems with this approach:
- difficult to keep track of what files are replaced, since you need to
cross-reference between directories
- too easy to start developing in the merges/android/ directory instead of
www/
2. Unified Merges Approach
app
|__ www/
|__ index.html
|__ myfile.js
|__ myfile.android.js
|__ myfolder/
|__ myfolder.android/
I've had much greater success with this approach.
When a file ends with a dot platform (optional extension) name (e.g.
myfile.android.js), it will be renamed to remove the platform name (e.g.
myfile.js). This will work on both files and directories.
This makes it extremely easy to keep track of what files and directories
are generic or platform specific. I haven't actually noticed any downside
to this approach and I used it for 2 years.
Thoughts?
Michael
Re: [cordova-cli] Merges Directory
Posted by Brian LeRoux <b...@brian.io>.
So, what would be better?
On Tuesday, March 26, 2013, Giorgio Natili wrote:
> The naming convention seems confusing also to me especially on big
> projects.
>
> On 3/25/13 10:46 PM, "Brian LeRoux" <b@brian.io <javascript:;>> wrote:
>
> >I'm apprehensive about returning to a naming convention. In a larger
> >app this would lead to a very cluttered dir.
> >
> >The other consideration for ./merges are other assets: icons, and
> >splashscreens. (Which would then require 2x or something for
> >retina/hdpi situations.)
> >
> >
> >
> >On Mon, Mar 25, 2013 at 2:34 PM, Michael Brooks
> ><michael@michaelbrooks.ca <javascript:;>> wrote:
> >> Just like to provide an alternative suggestion to the merges/ directory
> >>and
> >> here everyone's thoughts.
> >>
> >> While doing client work at Nitobi, each of our build scripts had similar
> >> functionality to merging platform-specific web assets. Below, I'll
> >>describe
> >> what I've experienced and make a suggestion on an improvement.
> >>
> >> 1. Separate Merges Directory
> >>
> >> app
> >> |__ merges/
> >> | |__ android/
> >> |__ www/
> >>
> >> In the above structure, the android/ directory is a mirror of the www/
> >> directory. When a file exists in the android/ directory, it will replace
> >> the file in the www/.
> >>
> >> I believe this is how the merges/ directory in `cordova-cli` works.
> >>
> >> I've experienced two main problems with this approach:
> >>
> >> - difficult to keep track of what files are replaced, since you need to
> >> cross-reference between directories
> >> - too easy to start developing in the merges/android/ directory instead
> >>of
> >> www/
> >>
> >> 2. Unified Merges Approach
> >>
> >> app
> >> |__ www/
> >> |__ index.html
> >> |__ myfile.js
> >> |__ myfile.android.js
> >> |__ myfolder/
> >> |__ myfolder.android/
> >>
> >> I've had much greater success with this approach.
> >>
> >> When a file ends with a dot platform (optional extension) name (e.g.
> >> myfile.android.js), it will be renamed to remove the platform name (e.g.
> >> myfile.js). This will work on both files and directories.
> >>
> >> This makes it extremely easy to keep track of what files and directories
> >> are generic or platform specific. I haven't actually noticed any
> >>downside
> >> to this approach and I used it for 2 years.
> >>
> >> Thoughts?
> >> Michael
>
>
>
Re: [cordova-cli] Merges Directory
Posted by Giorgio Natili <g....@gnstudio.com>.
The naming convention seems confusing also to me especially on big
projects.
On 3/25/13 10:46 PM, "Brian LeRoux" <b...@brian.io> wrote:
>I'm apprehensive about returning to a naming convention. In a larger
>app this would lead to a very cluttered dir.
>
>The other consideration for ./merges are other assets: icons, and
>splashscreens. (Which would then require 2x or something for
>retina/hdpi situations.)
>
>
>
>On Mon, Mar 25, 2013 at 2:34 PM, Michael Brooks
><mi...@michaelbrooks.ca> wrote:
>> Just like to provide an alternative suggestion to the merges/ directory
>>and
>> here everyone's thoughts.
>>
>> While doing client work at Nitobi, each of our build scripts had similar
>> functionality to merging platform-specific web assets. Below, I'll
>>describe
>> what I've experienced and make a suggestion on an improvement.
>>
>> 1. Separate Merges Directory
>>
>> app
>> |__ merges/
>> | |__ android/
>> |__ www/
>>
>> In the above structure, the android/ directory is a mirror of the www/
>> directory. When a file exists in the android/ directory, it will replace
>> the file in the www/.
>>
>> I believe this is how the merges/ directory in `cordova-cli` works.
>>
>> I've experienced two main problems with this approach:
>>
>> - difficult to keep track of what files are replaced, since you need to
>> cross-reference between directories
>> - too easy to start developing in the merges/android/ directory instead
>>of
>> www/
>>
>> 2. Unified Merges Approach
>>
>> app
>> |__ www/
>> |__ index.html
>> |__ myfile.js
>> |__ myfile.android.js
>> |__ myfolder/
>> |__ myfolder.android/
>>
>> I've had much greater success with this approach.
>>
>> When a file ends with a dot platform (optional extension) name (e.g.
>> myfile.android.js), it will be renamed to remove the platform name (e.g.
>> myfile.js). This will work on both files and directories.
>>
>> This makes it extremely easy to keep track of what files and directories
>> are generic or platform specific. I haven't actually noticed any
>>downside
>> to this approach and I used it for 2 years.
>>
>> Thoughts?
>> Michael
Re: [cordova-cli] Merges Directory
Posted by Brian LeRoux <b...@brian.io>.
I'm apprehensive about returning to a naming convention. In a larger
app this would lead to a very cluttered dir.
The other consideration for ./merges are other assets: icons, and
splashscreens. (Which would then require 2x or something for
retina/hdpi situations.)
On Mon, Mar 25, 2013 at 2:34 PM, Michael Brooks
<mi...@michaelbrooks.ca> wrote:
> Just like to provide an alternative suggestion to the merges/ directory and
> here everyone's thoughts.
>
> While doing client work at Nitobi, each of our build scripts had similar
> functionality to merging platform-specific web assets. Below, I'll describe
> what I've experienced and make a suggestion on an improvement.
>
> 1. Separate Merges Directory
>
> app
> |__ merges/
> | |__ android/
> |__ www/
>
> In the above structure, the android/ directory is a mirror of the www/
> directory. When a file exists in the android/ directory, it will replace
> the file in the www/.
>
> I believe this is how the merges/ directory in `cordova-cli` works.
>
> I've experienced two main problems with this approach:
>
> - difficult to keep track of what files are replaced, since you need to
> cross-reference between directories
> - too easy to start developing in the merges/android/ directory instead of
> www/
>
> 2. Unified Merges Approach
>
> app
> |__ www/
> |__ index.html
> |__ myfile.js
> |__ myfile.android.js
> |__ myfolder/
> |__ myfolder.android/
>
> I've had much greater success with this approach.
>
> When a file ends with a dot platform (optional extension) name (e.g.
> myfile.android.js), it will be renamed to remove the platform name (e.g.
> myfile.js). This will work on both files and directories.
>
> This makes it extremely easy to keep track of what files and directories
> are generic or platform specific. I haven't actually noticed any downside
> to this approach and I used it for 2 years.
>
> Thoughts?
> Michael
Re: [cordova-cli] Merges Directory
Posted by Brian LeRoux <b...@brian.io>.
> Arguments for or against either approach can usually be countered, because
> they solve the exact same problem.
Agreed. We have a working tested solution so lets keep it there until
such time as we see problems emerge.
> The platform resource problem should not be solved with the merges
> directory. The config.xml parser should move the platform's resources and
> delete the other platforms' resources.
I'm not so sure, the config.xml has become a dumping ground for all
these assets and its getting unwieldy with all the platforms as is.
Re: [cordova-cli] Merges Directory
Posted by Michael Brooks <mi...@michaelbrooks.ca>.
As a heads up, I'm not trying to sell the naming convention approach.
Simply, I've used both approaches for multiple projects between 2009-2012.
I've found the merges/ to become confusing, error prone, and encouraging a
platform-specific coding mindset.
I can see the benefits, but they seem somewhat minor, so I'd prefer the
compartmentalization of platform files. If I'm working on a specific
> platform, I can work in that platform's directory. Having the files spread
> out in a monolithic directory—especially once an app supports more than a
> couple of platforms—might get a little cumbersome.
Arguments for or against either approach can usually be countered, because
they solve the exact same problem. The main difference is organization and
being able to quickly eyeball whether a given file/folder will be replaced
by a platform-specific one. This important when you a generic www/ file
that is overwritten by only one platform. Too many times, I've edited the
generic file only to realize that there was also a platform-specific
implementation of it.
The other consideration for ./merges are other assets: icons, and
> splashscreens. (Which would then require 2x or something for
> retina/hdpi situations.)
The platform resource problem should not be solved with the merges
directory. The config.xml parser should move the platform's resources and
delete the other platforms' resources.
Michael
On Tue, Mar 26, 2013 at 8:36 AM, Max Woghiren <ma...@chromium.org> wrote:
> I can see the benefits, but they seem somewhat minor, so I'd prefer the
> compartmentalization of platform files. If I'm working on a specific
> platform, I can work in that platform's directory. Having the files spread
> out in a monolithic directory—especially once an app supports more than a
> couple of platforms—might get a little cumbersome.
>
>
> On Mon, Mar 25, 2013 at 5:34 PM, Michael Brooks <michael@michaelbrooks.ca
> >wrote:
>
> > Just like to provide an alternative suggestion to the merges/ directory
> and
> > here everyone's thoughts.
> >
> > While doing client work at Nitobi, each of our build scripts had similar
> > functionality to merging platform-specific web assets. Below, I'll
> describe
> > what I've experienced and make a suggestion on an improvement.
> >
> > 1. Separate Merges Directory
> >
> > app
> > |__ merges/
> > | |__ android/
> > |__ www/
> >
> > In the above structure, the android/ directory is a mirror of the www/
> > directory. When a file exists in the android/ directory, it will replace
> > the file in the www/.
> >
> > I believe this is how the merges/ directory in `cordova-cli` works.
> >
> > I've experienced two main problems with this approach:
> >
> > - difficult to keep track of what files are replaced, since you need to
> > cross-reference between directories
> > - too easy to start developing in the merges/android/ directory instead
> of
> > www/
> >
> > 2. Unified Merges Approach
> >
> > app
> > |__ www/
> > |__ index.html
> > |__ myfile.js
> > |__ myfile.android.js
> > |__ myfolder/
> > |__ myfolder.android/
> >
> > I've had much greater success with this approach.
> >
> > When a file ends with a dot platform (optional extension) name (e.g.
> > myfile.android.js), it will be renamed to remove the platform name (e.g.
> > myfile.js). This will work on both files and directories.
> >
> > This makes it extremely easy to keep track of what files and directories
> > are generic or platform specific. I haven't actually noticed any downside
> > to this approach and I used it for 2 years.
> >
> > Thoughts?
> > Michael
> >
>
Re: [cordova-cli] Merges Directory
Posted by Max Woghiren <ma...@chromium.org>.
I can see the benefits, but they seem somewhat minor, so I'd prefer the
compartmentalization of platform files. If I'm working on a specific
platform, I can work in that platform's directory. Having the files spread
out in a monolithic directory—especially once an app supports more than a
couple of platforms—might get a little cumbersome.
On Mon, Mar 25, 2013 at 5:34 PM, Michael Brooks <mi...@michaelbrooks.ca>wrote:
> Just like to provide an alternative suggestion to the merges/ directory and
> here everyone's thoughts.
>
> While doing client work at Nitobi, each of our build scripts had similar
> functionality to merging platform-specific web assets. Below, I'll describe
> what I've experienced and make a suggestion on an improvement.
>
> 1. Separate Merges Directory
>
> app
> |__ merges/
> | |__ android/
> |__ www/
>
> In the above structure, the android/ directory is a mirror of the www/
> directory. When a file exists in the android/ directory, it will replace
> the file in the www/.
>
> I believe this is how the merges/ directory in `cordova-cli` works.
>
> I've experienced two main problems with this approach:
>
> - difficult to keep track of what files are replaced, since you need to
> cross-reference between directories
> - too easy to start developing in the merges/android/ directory instead of
> www/
>
> 2. Unified Merges Approach
>
> app
> |__ www/
> |__ index.html
> |__ myfile.js
> |__ myfile.android.js
> |__ myfolder/
> |__ myfolder.android/
>
> I've had much greater success with this approach.
>
> When a file ends with a dot platform (optional extension) name (e.g.
> myfile.android.js), it will be renamed to remove the platform name (e.g.
> myfile.js). This will work on both files and directories.
>
> This makes it extremely easy to keep track of what files and directories
> are generic or platform specific. I haven't actually noticed any downside
> to this approach and I used it for 2 years.
>
> Thoughts?
> Michael
>