I'm working with Michael off this discussion thread to get the code up to par.
Michael, feel free to update your pull request and ping this thread whenever you get a chance to update it. Then we can all take a look. On 2/12/13 10:15 PM, "Anis KADRI" <[email protected]> wrote: >I believe this is a valid request. I like the idea of having >platform-specific code only deployed to matching devices. >I looked at the pull request and it looks good but as Fil mentioned, it >needs some tests. > > >On Tue, Feb 12, 2013 at 11:07 AM, Brian LeRoux <[email protected]> wrote: > >> yes there is some issues w/ emulation in this approach but I think its >> a better architectural pattern for a universal project. we can make >> ripple w/ this style rather the other way around. >> >> On Tue, Feb 12, 2013 at 6:48 PM, Michael Wolf <[email protected]> >> wrote: >> > Have looked at suggesting folks mock in-browser using ripple... >>however >> > there are a few issues with that, firstly being simply doesn't work >>for >> > non webkit platforms (ie windows phone... yah the cli doesn't >>currently >> > support windows phone but no reason why it can't) ... Also while you >>can >> > mock to work in ripple, you still have to write code in your base www >> that >> > only runs in browser / ripple and mock for it (unless I'm doing it >>wrong >> > :) ), which then introduces this conditional code which then ends up >>on a >> > device (which I recommend people to shy away from when they can)... >> where as >> > using the merges folder for this purpose makes the existence of those >> > mocks a purely www artifact that never ends up on a device or native >> > emulator... >> > >> > But I'll also admit I haven't looked deeper into ripple to see if >>there >> is >> > an alternative there, because the merges concept just worked for us. >> > >> > mw >> > >> > On 2/12/13 12:05 PM, "Filip Maj" <[email protected]> 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" <[email protected]> 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 >> >>><[email protected]>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 >> >> >> > >>
