Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a cookbook entry about building single command applications #1810

Merged
merged 2 commits into from Oct 23, 2012

Conversation

stof
Copy link
Member

@stof stof commented Oct 13, 2012

This documents the way to achieve the use case requested in
symfony/symfony#3857

This documents the way to achieve the use case requested in
symfony/symfony#3857
@stof
Copy link
Member Author

stof commented Oct 13, 2012

@weaverryan I added it in the cookbook but I'm not sure about its location. Currently, all console cookbook entries are about the console in the full stack framework. This article is about the standalone component so it may be better to move it to the component documentation. what do you think about it ?

@wouterj
Copy link
Member

wouterj commented Oct 13, 2012

@stof I think components/console is a better location.

@weaverryan
Copy link
Member

Hey Stof!

I was waiting for someone to submit a PR like this, and of course it's you first :). This is the first entry that is really a "cookbook for the components" (since of course the normal cookbook is entirely for the framework). I agree with @wouterj that right now the best spot for this is in the components section. Fortunately, each component is still small enough that it should be pretty easy to find these other docs. I also think that when we have entries like this in the components docs, then we should have a "Learn More" section at the bottom of the main component's entry which lists these documents - similar to what we do already in the book.

So, if you agre @stof, can you move it to be a component?

Thanks as always!

*/
protected function getCommandName(InputInterface $input)
{
return 'my_command';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might need a small note here to make sure that it's clear that my_command is the "name" used inside the MyCommand below.

@stof
Copy link
Member Author

stof commented Oct 17, 2012

@weaverryan done. Btw, the Console component deserves many such articles, as it is really separate from others. And this is especially true now that people start documenting the console helpers, to avoid having the main page becoming too big.
I will let you manage the Learn more links.

weaverryan added a commit that referenced this pull request Oct 23, 2012
Added a cookbook entry about building single command applications
@weaverryan weaverryan merged commit 761975b into symfony:2.0 Oct 23, 2012
weaverryan added a commit that referenced this pull request Oct 23, 2012
This introduces the idea of having short "intro" chapters for each component, followed by lots of related docs. This is a model that we largely want to follow in the components and in the framework book itself (we also need more in-context cross-linking between documents).

I've also updated a few document titles to be more descriptive.
@weaverryan
Copy link
Member

Hey Stof!

I've added the "Learn More" section. This is our best model so far with how we should organize the component documentation (and really, certain chapters in the book should be shorter, with more inter-linking to cookbook articles).

Once we figure out #1822, we definitely should refactor to have a dedicated section for each helper, and then add cross-links from other places in the docs - like the How to create a Console Command Cookbook entry - to these helper docs.

I'm telling you mostly so that we don't forget :)

Thanks as always!

@stof stof deleted the single_command_tool branch January 3, 2013 15:14
@dordille
Copy link

Not sure if I did something wrong when trying to get this working but I needed to modify the initialize method of my command.

protected function initialize(InputInterface $input, OutputInterface $output)
{
        $input->setArgument('command', $this->getName());
}

Without doing this I received errors because the input argument command is never was set. This argument is required by the application definition, which gets merged into the command definition.

@xphere
Copy link

xphere commented Apr 30, 2013

And what about changing the default command?
I'm coding a standalone console application with multiple commands but I want to change the default one, while keeping the list behaviour.
Since list is hardcoded in Application::doRun, this can't be achieved easily without duplicating the whole method in a subclass and changing some parts.
Is there an easier and maintainable way?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants