Hi!
As I questioned in the laravel forums (http://laravel.io/forum/02-24-2014-injecting-data-model-repository-and-business-model-in-controller) I'm unclear on why you do this double injection.

Of course it is ugly to use things like $this->articleform->article->byId() but on the other hand does it rectify to load the Data Model two times? Why have you decided to do it like this?

Having real problems with this having just bought your book Chris. Absolutely driving me mad and I can see no reason why this isn't working. I have pasted my code http://laravel.io/bin/De0Xj#11 and also at http://stackoverflow.com/questions/27760392/how-do-i-solve-target-interface-is-not-instantiable-in-laravel-4.

I know you closed this off in #14 but I just cannot find a solution to this at all.

Hi Chris,

Thanks for your very helpful book! I'm implementing a lot of the techniques already.

One thing that has stymied me so far is in regards to using Eloquent methods on an injected model. According to line 96 in EloquentArticle.php you have done the following:

$foundTag = $this->tag->where('slug', $tag)->first();

So you have injected the TagInterface into the EloquentArticle class and are using the "where" method, on the Tag model, within EloquentArticle.

Every time I try to do something similar I get a "call to undefined method where()" which leads me to believe I don't have my eloquent model properly injected.

Can you help me here? Thank you!

Hello,

A question for you about the Impl\Repo\Article\EloquentArticle->create() method.

Are there any disadvantages to doing this instead?

public function create(array $data)
    {
        // Create the article
        $this->article = \Article::create(array(
            'user_id' => $data['user_id'],
            'status_id' => $data['status_id'],
            'title' => $data['title'],
            'slug' => $this->slug($data['title']),
            'excerpt' => $data['excerpt'],
            'content' => $data['content'],
        ));

        ....

        return $this->article->id;
    }

The benefit would be easy access to the newly created Article's Id, which I am trying to get to the controller for other purposes.

Thoughts?

Thank you! Your book is fantastic.
~Ryan

See this tweet.

Page 81

"Notifier" vs "Notification" interface.

From an email received:

Pg. 37: Line 93: 'articles' should be '$articles'
Pg. 39: Line 23: 'byPage($page, $rpp)' should be 'byPage($page, $perPage)'
Pg. 56: Why do you switch from 'contentController' to 'articleController'?
Pg. 61: Line 3: 'class ArticleFormValidator extends LaravelValidatorAbstract' should be 'class ArticleFormValidator extends AbstractLaravelValidator'
Pg. 62: Line 3: should be 'use Impl\Service\Validation\ArticleFormValidator' right? You are referring to a class that is not created until page 66.
Pg. 74: Line 9: Should there also be a 'protected $article;' here?

Is there any working example of testing on controller that use form processing as written in the book? I'm little confuse about how exactly to test controller with pattern like that. Is it necessary to test each method in the controller or is it enough just to test the the form processing class as a unit?

Should the comment on ArticleForm.php line 18 be

@var \Impl\Service\ValidationValidableInterface

instead of

@var \Impl\Form\Service\ValidableInterface

Check to see if this error still exists:

In the book you show the Eloquent models residing under the Impl/models directory. In the GitHub project page they reside under app/models. The autoloader can't load them if they are under the Impl/models directory without a binding, which the book doesn't have or explain.

The directory tree is incorrect in "The Repository Pattern" chapter right after the sentence: "Here’s our file structure again, with the ArticleInterface and EloquentArticle files:" (Kindle Locations 1104-1105) and right before the sentence: "With our new implementation, we can revisit our controller: app/ controllers/ ContentController.php" (Kindle Locations 1116-1117). It shows the models directory residing under the Impl directory. This is from the latest version from Leanpub.

Hi Chris,

I have purchased and just finished reading your book. It's excellent - Thanks.

I really like the way you structure the sample application and I'm very keen to use your approach in an upcoming application of my own.

I downloaded the most recent release of the same application from GitHub - and I followed the instructions on installing the application. We I ran the sample application I got the error message 'FatalErrorException - Class 'Memcached' not found' which occured at line 40 in 'vendor\laravel\framework\src\Illuminate\Cache\MemcachedConnector.php'

My development environment is XAMPP running on Windows 7, so I followed the instructions here: http://www.leonardaustin.com/t... to install memcached on XAMPP running Windows 7. The installation appears to be working well with no errors when running the test code provided by the author of the article.

However, after restarting my development environment I still get the error message 'FatalErrorException - Class 'Memcached' not found' when I try to run your sample application.

Am I missing some specific configuration of memcached required for Laravel 4 or your sample application?

I have successfully developed and ran Laravel 4 applications on my development machine previously, although not with memcached.

Any help would be greatly appreciated as I am keen to explore your sample application further and learn more.

Thanks in advance.

Kind Regards

Walter

Hi Chris,

I'm coding my way through your book (really liking it so far), but am stuck on the "Going Further" section on pg 41.

The EloquentArticle class that gets created on page 35-38, has a dependency on TagInterface, so theoretically any implementation of TagInterface should be equally valid (hopefully I'm right so far). So I have the following TagInterface:

interface TagInterface {
    public funcition byTag($slug);
}

and a corresponding EloquentTag class that looks a tag up by its slug.

Where I'm confused is in this bit of the EloquentArticle::byTag function (pg 37):

$articles = $this->tag->articles()
    ->where('articles.status_id', 1)
    ->orderBy('articles.created_at', 'desc')
    ->skip( $limit * ($page-1) )
    ->take($limit)
    ->get();

Won't this only work on an Eloquent implementation of TagInterface? If I were to code an ArrayTag class, how would I use it with EloquentArticle?

Hi, Chris. Good book. Thoroughly enjoyed it.

I tried to reproduce your concept about Validation as Service, but I have error on Whoopsy.

What I did is simply following your book: create an ValidatingInterface, then create AbstractValidatingClass that implements ValidableInterface, then create ValidatingClass that extends AbstractValidatingClass.

ValidatingInterface is an exact copy of your interface, and AbstractValidatingClass is alsto an exact copy of your abstract class. While my ValidatingClass is still empty.

I instantiate ValidatingClass in my controller public __construct(ValidatingClass $validator) and when i call the controller, this is what I got from Whoopsy: Target [Symfony\Component\Translation\TranslatorInterface] is not instantiable.

This was resolved only after I added (thanks to the help in freenode chat) App::bind('Symfony\Component\Translation\TranslatorInterface', function($app) { return $app['translator']; });

Something like this is needed at the end of the Validation as a Service chapter. The next chapter includes one that is specific to the Form class, but users who don't go to that extent in their code is missing an important piece of information to make it work.

<?php namespace Impl\Service\Validation;

use Illuminate\Support\ServiceProvider;
use Impl\Service\Validation\SomeValidator;

class ValidationServiceProvider extends ServiceProvider {

    /**
     * Register the binding
     *
     * @return void
     */
    public function register()
    {
        $app = $this->app;

        $app->bind('Impl\Service\Validation\SomeValidator', function($app)
        {
            return new SomeValidator( $app['validator'] );
        });
    }

}

On Page 63/64 of the Validation as a Service chapter you show the controller's store method like:

// POST /article
public function store()
{
    if( $this->validator->with( Input::all() )->passes() )
    {
        // FORM PROCESSING
    } else {
    return View::make('admin.article_create')
        ->withInput( Input::all() )
        ->withErrors($validator->errors());
}

it should be ->withErrors($this->validator->errors());

Page 36 in PDF prepares the statement for a paginated result but instead it returns $articles->all(); in the StdClass.

Seems to be wrong?!

Hi there,

I have bought your book 'Implementing Laravel' and have also read most of your blog at Fideloper.com (including the post 'How to Create a Facade in Laravel 4').

From my reading, I understand the code and syntax of using both dependency injection as well as Facades, however, what I am not clear on is when you should use one or the other??

Could you possibly just outline a few simple guidelines as to when to use one or the other and the advantages/disadvantages of each approach?

In fact, it would be particularly helpful if you could add your post on Facades to the book and include a Facade in the 'Implementing Laravel' app to illustrate this distinction.

Many thanks for all your help to date. Both the Book and your blog are excellent!

[In reference to #2]

Since everyone in the PHP community (even outside of Laravel) are pushing tests now, I might (personally, of course) challenge your statement that tests aren't central to a book about creating an application using Laravel.

There are at least 3 people including myself who have questioned this. I, myself, have often questioned the need for testing. But we're coming to a point where the case cannot be ignored.

I do think having at least a couple of quick sample tests would help a great deal. Just something to show the practicality of testing, and instances where it may help us catch issues.

Hi,

While working through your book I tryed the shown approach with Repoistories.
In one example you do following:

use Illuminate\Database\Eloquent\Model;

and afterwards:

public function __construct(Model $article)
{
    $this->article = $article;
}

But when I want to duplicate this behaviour I receive following Error:
Target [Illuminate\Database\Eloquent\Model] is not instantiable.

Am I missing something ?

Just wondering. Thanks!

Page 8 of the e-book: App::make('paginator']

Hi Chris,

I'm coding my way through your book (really liking it so far), but am stuck on the "Going Further" section on pg 41.

The EloquentArticle class that gets created on page 35-38, has a dependency on TagInterface, so theoretically any implementation of TagInterface should be equally valid (hopefully I'm right so far). So I have the following `TagInterface

interface TagInterface {
    public funcition byTag($slug);
}

Where I'm confused is in this bit of the EloquentArticle::byTag function (pg 37):

$articles = $this->tag->articles()
    ->where('articles.status_id', 1)
    ->orderBy('articles.created_at', 'desc')
    ->skip( $limit * ($page-1) )
    ->take($limit)
    ->get();

Won't this only work on an Eloquent implementation of TagInterface? Maybe I'm missing something?

Error in your book "Implementing Laravel": Page 36, code line 47 - should be "return $result;" :-)

Hi !

By adopting the Repo pattern, I'm facing an issue with validating a "unique" field with validator. Here is my rule :

protected $rules = array(
        'name'    => 'required',
        'prefix'  => 'max:4|unique:ateliers'
);

And the error :

ERROR: exception 'RuntimeException' with message 'Presence verifier has not been set.' in (...)/vendor/laravel/framework/src/Illuminate/Validation/Validator.php:1726

What I understood is that the PresenceVerifier is used to count elements in database (to ensure it's unique), but since we use RepoInterfaces, it's broken.

How can I deal with that ?