laracasts / commander Goto Github PK

Hi,

It kinda seems like when specing a command handler that uses DispatchableTrait it becomes untestable with PHPSpec. Is this right, or have I missed something?

I've followed the instructions a dozen times now and get all kinds of errors. A demo project of a fresh install would be immensely helpful for getting started.

Maybe I'm just too used to generate:migration but it would be nice to be able to do this:

$ php artisan commander:generate Acme/Bar/SubscribeUserCommand --properties="first:string, last:Some\Class"

And have the docblocks updated in consequence

Hi Jeffrey,

For CommanderTrait I thought it might be handy to make mapInputToCommand in the execute method optional because sometimes you may wish to build up a command object that is not directly tied to a form input. For example, say you want to pass the currently authenticated user's id into the command. This value would not come from a form input, but directly from the controller. What do you think? Am I missing something totally obvious? As always, thanks, you do great work!

Just something to note. If the full namespace for the command also has command in it, it replaces all instances of it. Might be worth looking for it at the end of the line.

Hi,

When trying to include commander via composer I get error shown below:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: remove laravel/framework v4.2.7
    - Conclusion: don't install laravel/framework v4.2.7
    - Conclusion: don't install laravel/framework v4.2.6
    - Conclusion: don't install laravel/framework v4.2.5
    - Conclusion: don't install laravel/framework v4.2.4
    - Conclusion: don't install laravel/framework v4.2.3
    - Installation request for laracasts/commander 1.0 -> satisfiable by laracasts/commander[1.0].
    - Conclusion: don't install laravel/framework v4.2.2
    - Conclusion: don't install laravel/framework v4.2.1
    - laracasts/commander 1.0 requires illuminate/support 4.1.* -> satisfiable by illuminate/support[v4.1.0, v4.1.1, v4.1.10, v4.1.11, v4.1.12, v4.1.13, v4.1.14, v4.1.15, v4.1.16, v4.1.17, v4.1.18, v4.1.19, v4.1.2, v4.1.20, v4.1.21, v4.1.22, v4.1.23, v4.1.24, v4.1.25, v4.1.26, v4.1.27, v4.1.28, v4.1.29, v4.1.3, v4.1.30, v4.1.4, v4.1.5, v4.1.6, v4.1.7, v4.1.8, v4.1.9].
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.0
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.1
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.10
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.11
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.12
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.13
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.14
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.15
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.16
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.17
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.18
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.19
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.2
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.20
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.21
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.22
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.23
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.24
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.25
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.26
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.27
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.28
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.29
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.3
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.30
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.4
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.5
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.6
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.7
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.8
    - don't install laravel/framework v4.2.0|don't install illuminate/support v4.1.9
    - Installation request for laravel/framework 4.2.* -> satisfiable by laravel/framework[v4.2.0, v4.2.1, v4.2.2, v4.2.3, v4.2.4, v4.2.5, v4.2.6, v4.2.7].

Is it possible to bump illuminate/support requirements to 4.2 or is it package dependant?

Hey,

Just wondering how I would go about getting the newly created entry in my controller after using the command. $this, doesn't get any useful information. The only way I see would be to request the database again, but if I can avoid a DB call I'll be glad.

Thanks for any help

You could put a condition "if (is_array($input)) {" in mapInputToCommand method?

Would be pretty cool!

I've been struggling with how to handle related models.

At the moment, my requirement is to associate an image with a post.

post = [
    'body' => 'body text',
    'image_ids' => [1,2]
];

I validate the data and execute a new PublishPostCommand.

Should there be an AttachImagesToPostCommand? (and if so, how do we get the Post model outside the command?)

Or, within the PublishPostCommand should there be a repository call like:

$this->postRepository->save($post);
$this->postRepostiory->attachImages($command->image_ids);

(and if so, how do we get the Post model outside the postRepository?)

Or, within the save method of the postRepository, should there be logic to handle the attachment? (if, then attach statements)?

$this->postRepository->save($post, $command->image_ids);

I hope the question is clear. None of my solutions fall into place so I'm assuming I'm missing something.

Thanks to anyone who can help.

... at the end of the tunnel I'm assuming there's something like this in the postRepository

public function attachImage(Post $post, $image_ids)
{
    foreach($image_ids as $image_id)
    {
        $post->images()->associate($image_id);
    }
}

I recently hit a snag with using the CommanderTrait with a class inheriting from Illuminate/Console/Command. Because CommandTrait declares its own execute() method, there is a signature conflict with the method declared in Illuminate/Console/Command.

The solution I came up with was to create a class, CommanderExecutor, that uses the CommanderTrait and inject an instance of that CommanderExecutor as a class dependency, then referenced the object to invoke execute(). It's a little bit hacky, but it works

I used the validation decorator in many cases. Now I use a different approach to do validate the data. When I deleted the Validator classes, I got a File not found Exception.
I tried a composer dumpautoload then everything worked fine again.

One of my command DTOs are not getting passed through properly.

I don't know why. it is very weird... All of my other commands work fine...

# in controller
$this->execute(new ScrapeMovieReviewFeedCommand($url));

dd() in the controller gives me the expected value.

dd() in the Command gives the expected value.

dd() in the CommandHandler gives me:

object(Acme\MovieReviews\Commands\ScrapeMovieReviewFeedCommand)#339 (1) { ["url"]=> string(0) "" }

What could be the problem? I am drawing a blank...

I don't think this is currently an option from what I can see, but is there any way to override the default command.stub or handler.stub that the package uses when generating commands? It could be useful when a project has its own common patterns which each command uses. I'm finding in one project that I'm making the same changes to the default generated commands and handlers every time.

When i installed this package, I was no longer able to run any of my codecept unit tests. I get Duplicate UnitTester Defined. It was defined in this package. As soon as I removed this package, it allowed me to run my tests again.

Jeff,

When can we expect an update for the commander package that can be used in laravel 5? Currently the dependencies on the older versions (Support and Filesystem) prevent Commander from being included in laravel 5 projects.

I know that laravel 5 is currently in heavy development but trying laravel 5 out with this package would be awsome.

A temporary fix could be just updating the dependencies and stability for laravel 5:

{
    "name": "laracasts/commander",
    "description": "Commands and domain events in Laravel",
    "license": "MIT",
    "authors": [
        {
            "name": "Jeffrey Way",
            "email": "[email protected]"
        }
    ],
    "require": {
        "php": ">=5.4.0",
        "illuminate/support": "~5.0",
        "illuminate/filesystem": "~5.0",
        "mustache/mustache": "~2.6"
    },
    "require-dev": {
        "phpspec/phpspec": "~2.0.0",
        "codeception/codeception": "~2.0.0"
    },
    "autoload": {
        "psr-0": {
            "Laracasts\\Commander": "src/"
        }
    },
    "minimum-stability": "dev"
}

Hey Jeffrey!

I am trying to do method injection in a CommandHandler class like so:
public function handle($command, \UserRepository $userRepository)

Still, I'm getting the following error:
Declaration of Site\Registration\RegisterUserCommandHandler::handle() must be compatible with Laracasts\Commander\CommandHandler::handle($command)

Is it even possible to do method injection here?

Hey Jeffrey!

Is Commander coming to Laravel 4.3? I want to start using Laravel 4.3 and this is the last dependency I need to start working with 4.3.

Since the last update I always get the error 'Maximum function nesting level of '100' reached, aborting!' when I use the commander in my application (Larabook).

I have created a so called decorator and passed it to the execute method like so

$this->execute( ImportPlayerCommand::class, $input, [
                'ImportPlayerPositionConverter'
            ] );

the decorator isn't doing anything yet

use Laracasts\Commander\CommandBus;

class ImportPlayerPositionConverter implements CommandBus {

    public function execute( $command ) {
       die('dddddd');
    }

}

the error thrown is: Call to undefined method Laracasts\Commander\ValidationCommandBus::decorate()

regards,
Ronnie

Hi,
i'm trying to use the CommanderTrait inside an artisan command, but i receive the following error:
{"error":{"type":"ErrorException","message":"Declaration of Laracasts\\Commander\\CommanderTrait::execute() should be compatible with Illuminate\\Console\\Command::execute(Symfony\\Component\\Console\\Input\\InputInterface $input, Symfony\\Component\\Console\\Output\\OutputInterface $output)","file":"\/Users\/lucacri\/Sites\/YodaImporter\/app\/commands\/ReassignVncPorts.php","line":77}}

From what i can see, the Illuminate\Console\Command has already an execute method in line 110:
protected function execute(InputInterface $input, OutputInterface $output)

and it's not working well with the CommanderTrait. Any suggestion on how to fix it?

I prefer to use this command bus, as it returns values from a command
in the opposite of the new laravel 5 command bus that doesn't return value.

I have CommandA with ONE decorator class.

I have CommandB with NO decorator classes.

In CommandA handler, I execute CommandB.

By right, when I execute CommandA, these steps should happen:

1- Decorator of CommandA should be executed
2- CommandA handler should be called
3- CommandB handler should be called

However, I found that the decorator class of CommandA will execute twice:

1- Decorator of CommandA is executed
2- CommandA handler is called
3- Decorator of CommandA is executed again
4- CommandB handler is called

I managed to fix the issue by adding this check to CommanderTrait->execute() function:

if (empty($decorators))
{
    $bus->emptyDecorators();
}

where emptyDecorators() is defined in CommandBus implementation as:

/**
* Remove all 
*/
public function emptyDecorators ()
{
    $this->decorators = [];
}

Thanks.

When I use a decorator to sanitize data passed to the command, I would like to have that be executed before the validationCommand. The method below is from the ValidationCommandBus, but I've switched the $this->executeDecorators($command); with $this->validateCommand($command);.

Does swapping the order make sense for somebody else too? I can imagine there will be situations where this is not working as wanted (because you do want it to be validated first), but I would love to hear others opinions.

/**
 * Execute a command with validation.
 *
 * @param $command
 * @return mixed
 */
public function execute($command)
{
    // Next, we'll execute any registered decorators.
    $this->executeDecorators($command);

    // If a validator is "registered," we will
    // first trigger it, before moving forward.
    $this->validateCommand($command);

    // And finally pass through to the handler class.
    return $this->bus->execute($command);
}

One workaround would be to ignore the Validator decorator naming convention and making a JobValidator and add it after the JobSanitizer.

$this->execute(PostJobListingCommand::class, null, [
    'Acme\Job\JobSanitizer',
    'Acme\Job\JobValidator'
]);

Using "laracasts/commander": "~1.0" with Laravel 4.2 I get the following warning when doing composer update. Any clues?

Warning: Ambiguous class resolution, "Illuminate\Foundation\Application" was found in both
"/var/www/adsf/htdocs/vendor/laravel/framework/src/Illuminate/Foundation/Application.php"
and "/var/www/asdf/htdocs/vendor/laracasts/commander/spec/Laracasts/Commander/ValidationCommandBusSpec.php", the first will be used.

Hi guys,
this is a not real issue, but i want to tell you what i mean.
Sometimes we need to process a lot of data, and not only a few like in the larabook's lesson.
So in this situation the mapInputToCommand method doesn't works like we expect, if we think that we have an array like params for the construct, similar to something like that:

    public function __construct(array $attributes)
    {
        $this->attributes = $attributes;
    }

what can we do ? I must simply ignore the mapInput method ? Or is a mistake think like that ?

I was following Laracast video on Commander. However, when I ran it I kept getting 502 bad gateway error. I've narrowed the cause down to when I inject CommandBus into registrationController __construct. As soon as I remove it, I no longer get 502 error. However, when I put it back in and run it through Codeception I see that it runs into an infinite recursion.

PHP stack trace shows this:
PHP 38. Illuminate\Foundation\Application->make() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Routing/ControllerDispatcher.php:78
PHP 39. Illuminate\Container\Container->make() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:463
PHP 40. Illuminate\Container\Container->build() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Container/Container.php:432
PHP 41. Illuminate\Container\Container->getDependencies() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Container/Container.php:543
PHP 42. Illuminate\Container\Container->resolveClass() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Container/Container.php:576
PHP 43. Illuminate\Foundation\Application->make() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Container/Container.php:617
PHP 44. Illuminate\Container\Container->make() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:463
PHP 45. Illuminate\Container\Container->build() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Container/Container.php:432
PHP 46. Illuminate\Container\Container->Illuminate\Container{closure}() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Container/Container.php:507
PHP 47. Laracasts\Commander\CommanderServiceProvider->Laracasts\Commander{closure}() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Container/Container.php:216
PHP 48. Illuminate\Foundation\Application->make() /vagrant/finit/vendor/laracasts/commander/src/Laracasts/Commander/CommanderServiceProvider.php:56
PHP 49. Illuminate\Container\Container->make() /vagrant/finit/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:463

All of a sudden, all of my commands are throwing this error. I tried increasing the limit, but it appears there is a loop somewhere.

protected function getAlias($abstract)

Is the line that's throwing it, and it only happens when I execute a command (any command). Any ideas?

I have a checkbox that only exists in my post values when it's checked. When not checked, the value doesn't exist in Input::all() resulting in a InvalidArgumentException when mapping the input to the command. I toughed to be smart and gave the parameter a default value of null, this way the command executes when the checkbox is not checked, but when it's checked the value stays null. After reading theCommanderTraid::mapInputToCommand method I realised that it's coded in this way.

Though, I'm curious what people think of an approach where, when you don't always have the input available, you can give a default vale of null and make a check inside mapInputToCommand to see if the default value of the parameter is different to the value of the input from the same key. And if that's the case, assign the input value instead of the default value.

Hi!
I've noticed a strange bug when trying to use ValidationCommandBus. It appears that when executing command with this bus this decorator is firing validator then using the default command bus which is bound to another ValidationCommandBus via the service provider.

$this->app->bindShared('Laracasts\Commander\CommandBus', function ($app)
        {
            $default = $app->make('Laracasts\Commander\DefaultCommandBus');
            $translator = $app->make('Laracasts\Commander\CommandTranslator');

            return new ValidationCommandBus($default, $app, $translator);
        });

This code binds the interface to implementation of ValidationCommandBus so it is looping here for me. The version is 1.3.10.

Post request is fired after multiple changes on the page.

I have the CommanderTrait in one of my Controller (not resource) and when I see the list of routes, the route uri/command-bus comes out because the method start with get, or is public (or probably both). A quick fix might be setting the method visibility to protected, since no-one will call a method from a Controller.
Here's the route:

| | GET|HEAD auth/command-bus/{one?}/{two?}/{three?}/{four?}/{five?} |  | Pixel\Http\Controllers\Auth\AuthController@getCommandBus | | |

...

Hi,

I have the following logica in my app:
A command is creating a player which is firing a event which checks if the player already has an alias, if not it will create it using another command. The first command has a decorator. When the second command is firing it is also hitting the decorator given in the first command which should not happen.

Regards, Ronnie