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:[email protected]]
Sent: Tuesday, January 6, 2015 5:42 PM
To: [email protected]
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:[email protected]]
Sent: Tuesday, January 6, 2015 10:40 AM
To: [email protected]
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 KK[XZ[
] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
] Z[ ܙݘK \X K ܙ B
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
