I think 1.b sounds perfect. On Thu, Jan 8, 2015 at 5:48 PM, Murat Sutunc <mura...@microsoft.com> wrote:
> I think we have a couple of options here: > > Option 1 - Adding --list as an optional parameter to cordova run > List is related to run and there’s not that much need to introduce another > top level command for this . Considering all the previous discussions we > had I can see two potential implementations for this: > A) look at the parameters of run call in platform level > and take action > B) look at the parameters of run call in lib level and > take action > Option 1.A results in errors or unexpected behavior on platforms that do > not support --list (including older versions). > Option 1.B involves parsing arguments in > cordova-lib\cordova-lib\src\cordova\run.js (along with the cli). From this > point instead of calling project_root/platforms/<platform>/cordova/run we > can call project_root/platforms/<platform>/cordova/lib/list-* and so on. > > Option 2 - Adding ‘list’ as an optional parameter to a new command. > List can be put under a new top level command such as target. This design > involves adding a new top level command and corresponding handler in > cordova-lib. Similar to run, the code with logic will reside somewhere like > cordova-lib\cordova-lib\src\cordova\target.js. > > I would like to get some feedback about these options. > > -----Original Message----- > From: Murat Sutunc [mailto:mura...@microsoft.com] > Sent: Tuesday, January 6, 2015 5:42 PM > To: dev@cordova.apache.org > Subject: RE: Cordova --list option implementation > > The feedback is definitely very valuable. I was trying to understand the > issues with the existing design and once the impact is realized all the > commits are immediately reversed. > I'm currently looking into your suggestions and will try to come up with a > better design. > > -----Original Message----- > From: Josh Soref [mailto:jso...@blackberry.com] > Sent: Tuesday, January 6, 2015 10:40 AM > To: dev@cordova.apache.org > Subject: Re: Cordova --list option implementation > > Parashuram wrote: > >Josh, is your concern that ‹list throws an error in case of blackberry? > > No. my concern is that the way this was done was wrong <PERIOD>. > It doesn't work for *ANY* project that exists today with *ANY* platform. > > Cordova's design is to be backwards compatible. The code that was written > absolutely failed that. > > I tried to hint at that in my review comments. > > But that was totally ignored. > > Note that list threw an error in android (@released) too (as Andrew > belatedly noted). > > >We could fix that by either > >1a- Ignoring unknown flags like other platforms - and document the > >ignoring part as the default behavior > > This is too late. You can't really change the behavior because > cordova-cli/cordova-lib needs to support old projects with old platforms. > > >1b - or change other platforms to throw error on unsupported flags. In > >this case, ‹list would do the check to see if ‹list is implemented first. > > You can't do this for the same reason that we can't do 1a. > > >2. Implement ‹list for blackberry, thereby not having error on any > >platform. We could then have a separate discussion about what happens > >when a flag is not supported by a platform. > > It's not specific to blackberry10, it applies to all existing platforms > which happen to have the underlying support but which shipped without an > imaginary change to run.js > > >It would be great if we can let users use the ‹list functionality with > >minimal disruption to any platform. > > Correct. And this is trivially done -- put the code into cordova-lib and > have it run the scripts from the platforms, instead of requiring changes to > platforms — they already did the work they need to do (they are free to > replace their existing impls w/ node.js impls if they haven't already, but > that's transparent to cordova-lib). > B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB > [ X ܚX K K[XZ[ > ] ][ X ܚX P ܙ ݘK \ X K ܙ B ܈ Y ] [ۘ[ [X[ K[XZ[ > ] Z [ ܙ ݘK \ X K ܙ B > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org >
