Add MagentoStyle as Console Input/output helper object...

[wesleywmd]

...to allow easier access to io helpers in symfony/console

Description

Gives a helper object to access styling objects in symfony console easier.

How to use it

Instantiate inside a command object's methods (usually interact and execute but not limited to)
$io = new MagentoStyle($input,$output);

1. Titles: Creates a title header with a double bar underline
   $io->title("My Title");

2. Sections: Creates a section header with a single bar underline
   $io->section("My Section");

3. Content Output:
   Creates a text block
   $io->text("Your message here");
   Creates a bulleted list
   $io->listing(["item1","item2","item3"]);
   Creates a table
   $io->table(["header1","header2","header3"],[ ["A","B","C"], ["D","E","F"], ["G","H","I"] ]);
   Prints a new line
   $io->newLine();

4. Admonition Methods: success, warning, caution, note, comment
   Print out a padded and colored message
   $io->success("You Win!");
$io->error("You Fail!");

5. Progress Bar
   Creates an interactive progress bar
   $io->progressStart(100);
$io->progressAdvance(10);
$io->progressFinish();

6. Questions
   $io->ask("What is your name?");
$io->confirm("Are you sure?");
$io->choice("What is your favorite color?",["red,"blue","yellow"]);

7. Questions for missing arguments and options
   $io->askForMissingArgument( $argument, $question, $default = null, $validator = null, $maxAttempts = null, $comment = null, $commentFormat = "Argument [%s] set to: %s" )
$io->askForMissingOption( $option, $question, $default = null, $validator = null, $maxAttempts = null, $comment = null, $commentFormat = "Option [%s] set to: %s" )

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• [-] All new or changed code is covered with unit/integration tests (if applicable)
• [-] All automated tests passed successfully (all builds on Travis CI are green)

[magento-cicd2]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Wesley seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.

[fooman]

This code seems to be originating from
https://github.com/symfony/console/blob/master/Style/SymfonyStyle.php#L33
so I think there needs to be some additional verification that this is in line with license requirements of both the original code as well as Magento's CLA.

[orlangur]

I don't think implementation in such form is suitable for core. Some existing console commands should be refactored to use this new class.

@fooman is right, why don't we extend SymfonyStyle?

[wesleywmd]

@fooman, I initially thought of extending the SymfonyStyle object instead of creating a new one. THe problem is that outputBuffer as well a few other things are hidden behind private methods and those private methods are used throughout the pulbic facing methods. This makes extending those functions very hard without a lot of recreation.

As far as licensing goes, Symfony's documentation states, to create your own style object, implement the StyleInterface. I cannot speak to the magento licencing side of this. After work with the community engineers at the hackathon in NYC on this, I feel that it should be in line with licensing but I will defer this to someone that understands licensing better than me.

@orlangur, can you please explain why you feel it doesn't fit in core? I am proposing having a unified style object so all commands share a common style. So developers can focus on what their commands do and not how to style them. This object also opens a path for me to use this object to make all bin/magento commands interactive. Or at least the ones that make sense to do this with. I want to finish this object first before implementing it in every command.

[orlangur]

This object also opens a path for me to use this object to make all bin/magento commands interactive. Or at least the ones that make sense to do this with. I want to finish this object first before implementing it in every command.

Without using it in commands it would be hard to evaluate concrete implementation.

Why not refactor common styling part of existing commands into such object and then add some more functionality, like interactivity?

[orlangur]

extending the SymfonyStyle object instead of creating a new one

What would be the downsides if we use it as is? During implementation did you note a specific list of changes compared to Symfony implementation?

[wesleywmd]

Without using it in commands it would be hard to evaluate concrete implementation.

I plan to implement a much better set of unit tests that can show implementation in a better light.

I also plan to create a page in devdocs once/if this is accepted to illustrate its uses, the differences between this class and SymfonyStyle, and how to extend this object to add any other functions that maybe needed.

Basically, this is very much a work in progress.

What would be the downsides if we use it as is?

You can use the SymfonyStyle class as is. The styles are not as methodical. Example: using SymfonyStyle::warning() produces a red text block almost identical to an error block. The only real difference is that it says "[WARNING]" versus "[ERROR]". When using MagentoStyle::warning() the block is yellow instead to differentiate it from an error. I have also added a second optional parameter to drop the padding from any of the message functions.

MagentoStyle::askForMissingArgument() and MagentoStyle::askForMissingOption() are also not part of SymfonyStyle. These 2 methods are what I largely plan to use to make the existing commands interactive.

Why not refactor common styling part of existing commands into such object and then add some more functionality, like interactivity?

What common styling parts are you addressing? From what I have found, most of the styling is just done with tags and doesn't have much commonality other than color. If you have examples for common styling practices currently being used, can you please post them. I would like to look at this question deeper.

[orlangur]

From what I have found, most of the styling is just done with tags and doesn't have much commonality other than color.

I see, then this implementation is pretty much an extension of existing functionality.

If you have examples for common styling practices currently being used

I was referring just to implementation of existing commands. If they are not styled, there is nothing to "refactor" obviously.

In the very end (after arbitrary amount of related PRs, not just this one) will every command use such styling or some of them will remain plain?

[wesleywmd]

I am building this to be the standard styles for magento commands. I plan to refactor each core command to implement this style. Not all commands will benefit from being interactive but yes, they should all use the same styles.

This is also available for extension commands to also implement the standard styles for continuity.

Since this will be the standard for the styles, I would really like input on what the styles should be. I unfortunately cannot post a screenshot right now because I am afk. When I am back to my office, I will post a screenshot of what these styles look like.

[vrann]

@wesleywmd can you please fix the build failures

[magento-engcom-team]

@wesleywmd thank you for contributing. Please accept Community Contributors team invitation here to gain extended permissions for this repository.

[ishakhsuvarov]

Hi @wesleywmd
We have just noticed that Contributor License Agreement was not signed for this Pull Request.

Could you please add the email used for the commit in this PR to your github account and follow the link in the comment above?

Thank you for collaboration