Member Since 4 Years Ago

Experience Points

1,590 experience to go until the next level!

In case you were wondering, you earn Laracasts experience when you:

  • Complete a lesson — 100pts
  • Create a forum thread — 50pts
  • Reply to a thread — 10pts
  • Leave a reply that is liked — 50pts
  • Receive a "Best Reply" award — 500pts
Lessons Completed
Best Reply Awards
Best Reply
  • start-engines Created with Sketch.

    Start Your Engines

    Earned once you have completed your first Laracasts lesson.

  • first-thousand Created with Sketch.

    First Thousand

    Earned once you have earned your first 1000 experience points.

  • 1-year Created with Sketch.

    One Year Member

    Earned when you have been with Laracasts for 1 year.

  • 2-years Created with Sketch.

    Two Year Member

    Earned when you have been with Laracasts for 2 years.

  • 3-years Created with Sketch.

    Three Year Member

    Earned when you have been with Laracasts for 3 years.

  • 4-years Created with Sketch.

    Four Year Member

    Earned when you have been with Laracasts for 4 years.

  • 5-years Created with Sketch.

    Five Year Member

    Earned when you have been with Laracasts for 5 years.

  • school-session Created with Sketch.

    School In Session

    Earned when at least one Laracasts series has been fully completed.

  • welcome-newcomer Created with Sketch.

    Welcome To The Community

    Earned after your first post on the Laracasts forum.

  • full-time-student Created with Sketch.

    Full Time Learner

    Earned once 100 Laracasts lessons have been completed.

  • pay-it-forward Created with Sketch.

    Pay It Forward

    Earned once you receive your first "Best Reply" award on the Laracasts forum.

  • subscriber-token Created with Sketch.


    Earned if you are a paying Laracasts subscriber.

  • lifer-token Created with Sketch.


    Earned if you have a lifetime subscription to Laracasts.

  • lara-evanghelist Created with Sketch.

    Laracasts Evangelist

    Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.

  • chatty-cathy Created with Sketch.

    Chatty Cathy

    Earned once you have achieved 500 forum replies.

  • lara-veteran Created with Sketch.

    Laracasts Veteran

    Earned once your experience points passes 100,000.

  • 10k-strong Created with Sketch.

    Ten Thousand Strong

    Earned once your experience points hits 10,000.

  • lara-master Created with Sketch.

    Laracasts Master

    Earned once 1000 Laracasts lessons have been completed.

  • laracasts-tutor Created with Sketch.

    Laracasts Tutor

    Earned once your "Best Reply" award count is 100 or more.

  • laracasts-sensei Created with Sketch.

    Laracasts Sensei

    Earned once your experience points passes 1 million.

  • top-50 Created with Sketch.

    Top 50

    Earned once your experience points ranks in the top 50 of all Laracasts users.

Level 2
8,410 XP
02 Sep
2 years ago

FourStacks left a reply on Why Do I Get An Error When Applying A NameSpace To My Controller ?

@nordtek Thanks so much for posting that - this has been bugging me on an off for years! Usually solve it through a mix of swearing and endlessly rewriting/copy/pasting until it works!

15 Apr
2 years ago

FourStacks left a reply on I Would Like To Know Your Opinion

Hey @danielesposito

Hope you don't mind another viewpoint on this. @endian talks a lot of sense but I figured it couldn't hurt to offer another approach to your learning.

I was in pretty much your position about 2 years ago. I had an idea for an ambitious side project that I knew I'd never be able to build in Wordpress which, at that time, was all I'd really built sites in. Like you I tended to chuck any custom code for projects in a big procedural mess in the functions.php file which I knew wasn't really a great way of doing things, but I just had no idea with how to get started with learning OOP and web application development.

Simply put, Laravel and Laracasts (and some hard work) pretty much changed all of that. I started to look around for a framework to use to build the app I had in mind and in the end it was a toss up between Symfony and Laravel (which I believe was at 4.1 when I started). I chose Laravel and have never looked back.

Whilst @endian suggests that a microframework is a better choice for you, I'd probably on the whole disagree with that. Of course, it all depends on what you're building but the point of micro frameworks like Lumen is to build small, fast JSON APIs that will (generally) as as a microservice for some larger application (or act in concert with a bunch of other smaller services).

It's true that Laravel has many bells and whistles which might seem overwhelming at first but the nice thing about Laravel is most of these features are entirely optional - they're there for you if the needs of your app demand them but you're by no means required to learn about them all on day one. Most of the tutorials you'll come across will be for Laravel rather than Lumen, and the docs for Laravel are top drawer. Also, anecdotally, a lot of people who start of building something in Lumen find they end up needing features in Laravel eventually and end up migrating their app to Laravel anyway so unless you need to build a blazing fast API then I'd really recommend that you just start with Laravel and reach for a microframework if your use case demands it

Anyway, I'm in danger of rambling - I totally realise your milage may vary but if here's how I went from your position to where I am now

1 - Get a Laracasts subscription.

Everyone learns differently (though it sounds like you perhaps also learn best by doing) but for my money the best money you can spend if you're serious about learning this stuff is to get a Laracasts subscription. I'm serious - Jeffrey is pretty much the best teacher I've ever had (and never met) and that's from someone who's sat through two degrees-worth of lectures!

Once you've got access to the Laracasts archives I'd recommend you get going on the OOP bootcamp series and the intro to laravel series:

The OOP one in particular helped me bridge the gap from procedural soup code to the OOP approach you'll need to be familiar with to tackle web app development

There's a huge amount of content on here these days though and it's all pretty great so check out the archive and hit the beginner filter to see what's what. You won't regret it.

2 - Have a real project to build (one with real problems you have to solve).

Can't overstate this one enough. Sure, you could build another generic task app or twitter clone like 99% of tutorials out there but there's no substitute (IMO) for having an idea for an application that requires you to come up with solutions that tackle real-world problems (or at least ones that can be solved through code).

It sounds as though you have a project in mind which is great! It doesn't need to be world-changing or have a 100% chance of making you a ton of money to be worth building. My first project in Laravel was for an app that would allow local authorities to administer a new piece of legislation. It bombed in the end (mostly because I wasn't embedded enough in the community I was trying to sell it to) but I learned an absolute TONNE building it and all those new skills meant that I really levelled up in terms of the type of client and project I could take on afterwards.

3 - Be prepared to work pretty hard.

This one isn't meant o sound patronising - obviously, like any new skill you have to put the hours in to master it - but I wanted to list this because I was surprised but just how much work I had to put in to get that first project out the door. Maybe I'm just thick or a slow learner but I'd say it took me a good 3 months of more or less full time work to get to the point where I knew what I (vaguely) was doing. The whole project took about 6-8 months to go from an idea to a product I could show off to people.

I knew it was a worthwhile investment in time and luckily at the time my (supportive!) wife was employed full time and was cool about supporting us financially whilst I took time out from paid client work to learn all this stuff. I'm not saying this to put you off - more to give you some realistic expectations on how long it (might) take you to get up to speed.

4 - Read the docs

The Laravel documentation is pretty much some of the best I've ever read and you could probably learn how to build applications just by reading them (though some basic OOP knowledge would help you out a fair bit). Bookmark it, read it all as much you can as often as you can and it will help you loads. Then, when you're more familiar with OOP and how Laravel is structured I'd really recommend diving through the source code to see how things fit together - it's all commented really well and will help give you a deeper insight (though probably stick to Laracasts and the docs until you're more comfortable with it all)

Man this post is waaay longer than I'd planned! Sorry about that - hope some of the above is useful to you and best of luck - hope you enjoy learning all this as much as I did (or rather am).

20 Feb
3 years ago

FourStacks left a reply on Vuejs Loading Animation Or Fix?

Hi @stephan-v

Have you tried using the v-cloak directive on the component that's rendering the moustache tags?

That directive is specifically designed to hide this flash of uncomplicated content so give that a whirl

13 Jan
3 years ago

FourStacks left a reply on Checkboxes And V-model


No problem, glad it helped. As for your question re the isSelected method, you're kind of right in the sense that your v-model attribute on your checkboxes is evaluated when properties of your vue instance change. Therefore your toggleCheckbox method changes the state of your vue instance which in turn is then picked up by v-model which runs the isSelected function to figure out if the chockbox should be toggled or not.

That might not be the best explanation but then (a fair bit of) Vue's internals are a level of voodoo that's a bit beyond me. I can get it to work but sometimes I'm better off not asking 'why' it works too much!

FourStacks left a reply on Checkboxes And V-model

Sorry, just for clarity, it's worth pointing out that you can have a computed property act as a setter (as well as a getter which is the default) so the fact that the isSelected accepts a parameter isn't in itself the reason it should be a method, it's more that the function returns a boolean result for a given product so you're not really changing the state of an instance property which is more what computed properties are for.

More info on computed property setters though if you're interested

FourStacks left a reply on Checkboxes And V-model

Hey @El_Matella

I've forked your demo:

You were basically there, your main issue was that isSelected should have really been a method since it accepts a parameter. In your fiddle you had it as a computed property (incidently you had a typo on that - e.g. 'compute' instead of 'computed'

Either way, think the above fiddle should get you a bit closer hopefully!

17 Oct
3 years ago

FourStacks left a reply on Fetch Associative Array From Pivot Table And Pass It To View ?

You're welcome - glad it works for you!

FourStacks left a reply on Pivot Or Polymorphism?

Hmm...well to start with I think the idea of a collector model for the various tools seems like a sensible one. In fact that might simplify things a bit for you. The following suggestion may be off the mark as I'm not sure about the wider domain logic of your app so it might not have the required flexibility but let me know what you think.

So how about this:

You have your Tool model and table. This is a simple collector Model for the 4 different tool models ToolOne, ToolTwo etc.

Your Tool Model would have polymorphic association to each of the individual tool models like so

public function toolable()
    return $this->morphTo();

Each tool model would have the inverse relationship

public function tool()
    return $this->morphOne('App\Tool', 'toolable');

So then you would set up your Call model and table. This model/table contains the core properties unique to all calls and uses meta for the properties that are unique to each of the tool models.

You would then set a regular many-to-many relationship between Call and your main Tool model. You could instead set a relationship between Call and each of your tool tables but if you do you'll need to use a polymorphic many to many relationship instead.

At this stage you'd be able to query any given tool like so

// Get a generic tool from your tools table
$tool = App\Tool::find(1);

// Get the specific tool type from the polymorphic association
$toolOne = $tool->toolable; // example assumes that the first tool is related to a ToolOne model

// Get the calls for this model
$calls = $tool->calls;

// or if you go down the route of using a polymorphic relationship between Call and each tool model...
$calls = $toolOne->calls;

Would that work for your use case?

FourStacks left a reply on Pivot Or Polymorphism?

OK, complicated setup! I think you can simplfy things with polymorphism however without resorting to empty columns.

If this were my project I'd probably take a meta table approach to handle the 'edge' columns that are unique to Calls and Views.

So you'd have your 4 Tool/Widget tables with their 4 different models. You'd then have a Calls table and a Views Table with only the core (shared) properties. View and Call would have a polymorphic Many to Many relationship to each of the tool models and each of the tool models would have a corresponding polymorphic many to many relationship to Call and View.

So far this is like the demo in the docs only repeated 4 times (once for each tool).

To handle the edge columns using meta you could do one of two things. I've used this package before and it works great:

The big plus of this package is it allows you to make calls to get meta in a Fluent fashion, just as if the meta was a property on the model.

If you'd prefer not to use a 3rd party package for this though you could achieve a similar result (minus the fluent calls by setting up view_meta and call_meta tables (with view_id/call_id, key, value columns) and models then setting up a one to many relationship on the View/Call models and the reverse relationship on the meta models.

Does that make sense? Shout if not and i'll try to explain more clearly!

16 Oct
3 years ago

FourStacks left a reply on Pivot Or Polymorphism?

Hi @3ll0

Just to be clear, are your 4 Tools/Widgets all very different? E.g. the data structure for each is not shared between Tools?

It does sound like a good candidate for polymorphism to me though it might depend a bit on whether the Tools could all share a table rather than have separate tables/models.

FourStacks left a reply on Fetch Associative Array From Pivot Table And Pass It To View ?

Hi @darknesseyes

I'm assuming you have models for your Group and Subject tables with a belongsToMany relationship defined for each model (e.g. in the Group model you'd have a method called subjects and in your Subject model you'll have a groups method)? If so you'll probably want to do something like this in your controller:

public function myControllerMethod(){
    $groups = App\Group::with('subjects')->get();
    return view('my.view', compact($groups));

Then in your view you can iterate over your groups using blade syntax like so:

@if( ! $group->isEmpty() )
@foreach($groups as $group)
    <li>{{ $group->title }}
        @if( ! $group->subjects->isEmpty() )
            @foreach($group->subjects as $subject)
                <li>{{ $subject->title }}</li>

Think that should have you covered - it's a bit proto-code but you should hopefully get the gist. Shout if anything is unclear.

Edit - sorry, should probably mention that you'd be dealing with eloquent collections in the example above though you can easily convert to plain arrays using the all() collection method:

21 Jul
4 years ago

FourStacks left a reply on ReflectionException For Manually Added Controllers In 5.1.7

Can you post up your controller code? A possible cause might be an error in your namespacing perhaps?

03 May
4 years ago

FourStacks left a reply on What Should I Be Testing? Laravel 5 With A Command Architecture

Sorry to post another "me too" type reply but I'd also be very interested to hear others approach to this. My current app heavily embraces commands and events and I'm left wondering the best way to test the handlers for each.

Like @BenSmith I'm generally passing off any "work" in these handlers to repos or services which have their own tests so I'm guessing that mocking those methods to make sure they are called in the handlers is enough but I'd like to know whether others have a better way of doing things.

22 Mar
4 years ago

FourStacks left a reply on PHPUnit Says Route Not Defined

I was running into this exact same problem this morning. However, last night everything was hunky-dorey - all tests green. The change I made which caused the same InvalidArgumentException (route not found) was to chop up my routes file into partials and require each one within routes.php. Did this as my routes file was starting to get a little unweidly.

Weirdly, the routes themselves all worked just fine if I manually visited them and everything was fine when I ran php artisan route:list. It was just the phpunit tests that were failing. When I switched back to my original routes file everything went back to green.

Not sure whether those above with similar issues have done something similar to their routes file but if so then it might be the cause of the failing tests (not really a solution though I'm afraid...)

24 Nov
4 years ago

FourStacks left a reply on Is This Polymorphic Relationship Or DB Design Issue ?

Check out this blog post by Richard Bagshaw he sums a good approach pretty neatly. Going to be implementing this in a project I'm just starting and it sounds like it fits the bills for you too