I definitely think the use-case of per-platform files is valid. We already have this for plugin.xml I think, by putting <asset> tags within <platform>.
Solving it through directory structure instead of through config.xml is easier I think. We should think about solving this for splash screens images as well. On Tue, Feb 12, 2013 at 12:05 PM, Filip Maj <f...@adobe.com> wrote: > Cool, thanks Michael. I will take a look when I get a chance. Curious what > the rest of the list thinks. > > As for mocking in-browser, I recommend trying out Ripple - it has great > support for mocking out arbitrary cordova plugins. > > On 2/12/13 6:10 AM, "Gorkem Ercan" <gorkem.er...@gmail.com> wrote: > > >I have been cooking up a similar functionality for Cordova development > >plugins for Eclipse IDE that I am building. I think the only real > >difference with what I have is I have named the merges folder as > >www_platform. > > > >As my goal is to keep 100% compatible with cordova-cli I was planning to > >provide a PL for the same so I would be interested with this work and > >offer > >help if needed. > >-- > >Gorkem > > > >On Tue, Feb 12, 2013 at 6:28 AM, Michael Wolf > ><michael.w...@cynergy.com>wrote: > > > >> Hey all: > >> > >> I submitted a pull request for an enhancement of the addition of a > >>merges > >> folder/concept into the cli build process. > >> > >> https://github.com/apache/cordova-cli/pull/3 > >> > >> The concept of merges is pretty simple, to support a common core web > >>base > >> across platforms, but allow for deploying platform specific www content > >>to > >> specific platforms. The addition to the CLI tool adds a new folder > >> "merges" to the root level. Upon running "cordova platforms add|remove > >> platform" a new folder is created under the "merges" folder (ie: > >>merges/ios > >> , merges/android etc). Upon running "cordova buid" any content added to > >> this folder will be deployed to the associated www folder in the > >>platforms. > >> This carries for either new content being added, or more importantly > >> overrides existing content from the www folder. For a very simple > >>example > >> imagine you have a css file named css/chrome.css in the www folder, > >>where > >> you could have .backButton { display:block;} , but then under > >> merges/android/css/chrome.css you could have .backButton{display:none;}, > >> this is a very simplistic use but it illustrates the concept. This > >> additional workflow to the build system in the cli enables some great > >> processes for building a nice clean cordova app for example. > >> > >> > >> * Allows for keeping code clean and limits the need for platform > >> specific js logic per platform > >> * Enables a process of mocking in custom plugins for in browser dev > >> (mocks under www real implementations under merges) , and not risking > >>this > >> code filtering into production/device code > >> * Allows for creating platform specific assets such as css / font / > >> images/ videos etc that only gets merged into the specific desired > >>platform > >> * Allows for accepting that each platform is unique and sometimes > >>need > >> specific logic and or shims, and always deserves the platform specific > >> love, and the build process should support doing this cleanly > >> > >> Anywho Š.. Would love to see this integrated in. > >> > >> Thanks > >> > >> mw > >> > > > > > > > >-- > >-- > >Gorkem > >http://www.gorkem-ercan.com > >
