LeonardChallis

LeonardChallis

Member Since 2 Years Ago

Experience Points 4,640
Experience Level 1

360 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 44
Lessons
Completed
Best Reply Awards 0
Best Reply
Awards
  • 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.

    Subscriber

    Earned if you are a paying Laracasts subscriber.

  • lifer-token Created with Sketch.

    Lifer

    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.

13 Aug
6 days ago

LeonardChallis started a new conversation Return A HasMany Relationship For A Child Object

I have two types of object: Level and Game. Every Level can have exactly one parent Level (or none, if it's the first level). But Levels can have multiple children. This creates a sort of hierarchy/family tree type structure that can change as new Levels are added. This is achieved on Level with a parent() (belongsTo relationship) method and a children() (hasMany() relationship) method.

Game objects specify a specific path of Levels, from first parent (where its parent is null) right down to a specific sub-Level, however far down the hierarchy. The way I have set this up is by giving Game a finalLevel() (belongsTo() relationship) method, pointing at said specific sub-Level. The idea then would be to recurse up until there are no more parents, when a whole Game had to be loaded. On the Level side, there is currently a games() (hasMany() relationship) method. However, this only returns the Game when the Level in question is the final one.

I've hit the point now where I want to figure out what Games any given Level belongs to, but anywhere in the hierarchy, not just the final Level. Is there a way I can alter the games() method so that it can recurse through a Levels children to see if it can find any more Games and return that Level's hasMany() relationship instead?

Or, is there a better pattern I should use for this?

I'm happy to do a bit of restructuring for the sake of cleaner code. I did consider adding a many-to-many relationship where Levels would have a relationship to both their parent and the Game, then somehow figure out the ordering of Levels when loading them from the Game object, but I'm not sure if that would be overkill?

Any advice would be greatly received, thanks!

06 Oct
1 year ago

LeonardChallis started a new conversation Can I Restrict Columns With Implicit Binding?

My overall goal is to implement ?fields=xxx,yyy,zzz for all my endpoints to let consumers limit which fields are returned. I'm using resource controllers with implicit binding.

Would it be possible to write middleware to do this? Or is it impossible with implicit binding, forcing me to be explicit?

Things I've tried

In my models: protected $visible = ['xxx', 'xxx']; I didn't further explore this one as accessing query string data here in the model seemed like a bad idea.

Then I wondered if I could do something like this in my routes:

public function show(Category $category)
{
    return $category->makeVisible('xxx');
}

Apart from the fact that still returns all the fields, I also want to make sure the query to the database restricts the columns too as surely this is just a waste of resources otherwise.

I then looked at something like this in RouteServiceProvider:

Route::bind('category', function ($value) {
    return Category::where('id', $value)->select('id', 'reference')->first();
});

Not sure if custom resolution just to get the columns I want is the right way to go though, and besides that I suspect most the benefits of implicit binding are lost here too.

13 Sep
1 year ago

LeonardChallis left a reply on More Automated Way To Create Common API Routes

The gets are indeed a typo - but yes the Route::resource stuff I managed to skip over, my bad! Thanks for the clarification!

LeonardChallis left a reply on More Automated Way To Create Common API Routes

@Dry7 That's exactly what I am doing - using prefixes and generating resource controllers. But unless I've missed something this doesn't automate any of the route creation.

LeonardChallis started a new conversation More Automated Way To Create Common API Routes

Bear with me if I'm missing something obvious (i.e. that'll come later in the awesome "from scratch" Laracast series!) but I've started using Laravel to make an API and I've found I've got a lot of places where I want the same routes setup for resource controllers. So usually I'd have a bunch of standard REST routes like this:

Route::get('/photos', '[email protected]')->name('photos.index');
Route::get('/photos/create', '[email protected]')->name('photos.create');
Route::get('/photos', '[email protected]')->name('photos.store');
Route::get('/photos/{photo}', '[email protected]')->name('photos.show');
Route::get('/photos/{photo}/edit', '[email protected]')->name('photos.edit');
// etc

Couple this with the fact that I want to use multiple prefixes (so I might have routes like /shipping/type/create, /shipping/zone/store, etc) and there may be multiple different levels, it seems quite tedious to be writing these all out again and again.

I came up with a quick solution which works, though seems a little dirty:

// specify REST actions
$restActions = [
    [
        'verb' => 'get',
        'uri' => '',
        'action' => 'index',
    ],
    [
        'verb' => 'get',
        'uri' => '/create',
        'action' => 'create',
    ],
    [
        'verb' => 'post',
        'uri' => '',
        'action' => 'store',
    ],
    // etc etc
];

// specify my own models
$prefixes = [
    'Shipping' => [
        'Type',
        'PostalCodeType',
        'Location',
    ],
    'Supplier' => [
        'Service',
        'ProductType',
    ],
    // etc etc
];

// setup the routes
foreach ($prefixes as $prefixName => $prefixArray) {
    foreach ($prefixArray as $prefix) {
        Route::prefix(strtolower($prefixName))->group(function () use ($restActions, $prefixName, $prefix) {
            foreach ($restActions as $restAction) {
                Route::prefix(strtolower($prefix))->group(function () use ($restAction, $prefixName, $prefix) {
                    Route::{$restAction['verb']}(str_replace(':name', strtolower($prefixName) . $prefix, $restAction['uri']), $prefixName . $prefix . '[email protected]' . $restAction['action'])->name(strtolower($pref  ixName . $prefix) . '.' . $restAction['action']);
                });
            }
        });
    }
}

This works as expected, and allows me to add more models and know that I don't have to write more routes, but is there a(n accepted) better way of achieving this?

Also would be interested in hearing thoughts on namespacing here - because I found doing php artisan make:model -mcr but specifying namespaces (so in my above example, it could be Shipping\PostalCodeType or Supplier\Service for instance) seemed to break the automatic binding.

Thanks for any tips or links to relevant docs!

30 Aug
1 year ago

LeonardChallis left a reply on Incrementally Implement Laravel Into Legacy System - Consuming API?

So there's nothing I could do like this, which can be done with the Slim framework:

$env = \Slim\Http\Environment::mock([
    'REQUEST_METHOD' => 'PUT',
    'REQUEST_URI' => '/foo/bar',
    'QUERY_STRING' => 'abc=123&foo=bar',
    'SERVER_NAME' => 'example.com',
    'CONTENT_TYPE' => 'application/json;charset=utf8',
    'CONTENT_LENGTH' => 15
]);

https://www.slimframework.com/docs/cookbook/environment.html

24 Aug
1 year ago

LeonardChallis left a reply on Incrementally Implement Laravel Into Legacy System - Consuming API?

Thanks @danmatthews some really good points to note - nice to see we're not alone in this scary position ;) One thing I should have pointed out is that we're tempted to separate data away as well - two separate databases might sound a little sinister but if I showed you some of the database "conventions" used on the current project you'd understand what I'm getting at... let's just say the system rewrites database structure on the fly and there's a lot of "pruning" needed to maintain it currently :|

As for the web request, I see what you're saying. But can this be mocked in any way? I have seen things like $request = Request::create(...); $response = Route::dispatch($request) and app()->handle() suggest but I'm not quite at the point I can say whether they're going to be options for us yet, but potentially could they improve speed? I don't like the idea of relying on an HTTP request inside a page load if I can help that kind of thing. Tell me if I'm barking up the wrong tree here!

LeonardChallis started a new conversation Incrementally Implement Laravel Into Legacy System - Consuming API?

I've recently started learning Laravel and so far, I love it. One of my upcoming projects is to take a very old eCommerce system (started off in PHP 4, hacked to death over the years) and end up, over as long a period of times as needs be, with a comparable system that runs entirely in a new framework (i.e. Laravel). This is while the old system has fixes and updates alongside too.

I've been looking into ways of doing this without an all-or-nothing approach. I want to replace smaller parts of the system, modularising as much as I can with my team, until we feel confident that enough of the functionality is in place for us to make a final big push to move over things like web routes and use Laravel as one would traditionally expect. Bear in mind that this current system has very few classes or separation of concerns, tons of functions with global variables, etc. For all intents and purposes it is removing chunks of procedural code with calls to Laravel. We don't care about the old system getting (more) hack, but the new system we want to be clean and reusable, regardless.

I was wondering if anyone had any thoughts or could point me towards relevant reading for this sort of thing. I was thinking that if I created new features that could be accessed through an API (for instance shipping functionality, stock control, etc), then the existing system could make calls to that API and this same API would be used in the final system. Can that be done from other, non-laravel apps, without an actual HTTP request? Note: they will be on the same server, of course.

Unfortunately we don't currently have the resources to make a system from scratch to do a full on replacement, and the risks would be huge here too. Has anyone got any experience, tips, tricks or warnings for tackling our problem of a very old system this way?

Many thanks!