Error processing prado-cli command line arguments

[carlosbfeitozafilho]

I'm trying to overwrite some table class files and for that I'm using the following command line:

.\protected\vendor\bin\prado-cli activerecord/generate-all Application.database false overwrite

But I always get the same response:

*----------------------------------- Error ------------------------------------*
* File *
* D:\Development\PHP\Projects\PradoBlog\protected\database\Users.php *
* already exists, skipping. *
*------------------------------------------------------------------------*

When investigating the source code I noticed two things, first that the way command line arguments are being handled considers their position in the command line (that's why I needed to include "false" before "overwrite"). Second, when the "actionGenerate" function is executed, it checks for the presence of the "overwrite" argument and sets the value to true in $this->_overwriteall, but later on it is checking the field $this->_overwrite, which invariably has false because I am executing the generate-all command (and not generate)

This bug needs to be fixed so that people don't have to delete their table class files before running the command. Additionally, it would be very desirable to change the way command line arguments are obtained so that the simple presence of one of these arguments in any position, and without the need for the inclusion of other arguments, is sufficient.

I also found that the problem with the way to get the command line arguments is preventing the creation of files with prefix/suffix, for example, it is not possible to create files with suffix without prefix

[ctrlaltca]

Confirmed. Three problems:

• the overwrite parameter is broken because of bad variable usage
• parameter handling is fragile and prone to errors
• relation creation is missing (borrow/merge from wsat)
  Please use https://github.com/pradosoft/prado-wsat until these issues gets fixed

[belisoful]

I was tempted to address the parameter handling issue in the last CLI update... It was something that would have taken more time and energy than I had. Plus would require at least some discussion with the community.

The issue is how parameters are handled. Is backward compatibility necessary? and how should the parameters be handled?
0) set arguments for an action?

1. --parameter=false, or
2. --parameter false
3. or both 1 & 2, requiring each parameter to identify its variable, where the presence of the '=' turns off the following argument as the variable. And how does option 0 fit into 3? (are arguments with -- stripped from the arguments of the action)

For option 3: does the variable exist? or is it just a flag? This is where cataloging all the actions arguments would take time to code and unit test.

This does not address the issues with the specific action(s).

[carlosbfeitozafilho]

Allow me to make some suggestions (without taking into account backwards compatibility)

• For parameters that have a value, the most correct way, in my understanding, is to use the format --parameter=value (without whitespace around =). Using spaces to separate a parameter from its value makes parameter manipulation as a whole more complex and much more susceptible to user errors.

• If the value can have spaces, like a string, always use --paramenter="value with spaces"

• If the parameter is a flag, its simple presence on the command line already indicates that it is activated, so there is no need to do --flagparameter=true, because this is redundant

• Whenever possible, parameters should have default values ​​so that we don't need to enter each one every time. In the case of parameters that are flags this applies in the same way as long as the name of the parameter indicates what it does, for example, a parameter that would indicate "do not process entities" that has a default value of false would have the exact name of what it does, --donotprocessentities and if it exists on the command line it would mean that entities should not be processed and in other words it would mean $doNotProcessEntities = true;

• Using parameter detection in this way allows parameters to exist anywhere on the command line without affecting other parameters

• Take the command line as a whole and explode it according to its whitespace (parameter separators) and process the resulting array to define what needs to be done. Even if some parameters need to be in fixed positions, for example, at the beginning of the command line, I believe it is simpler to have each parameter and its value in an element of an array.