[PHP] Het grote Laravel topic

[Barryvdh]

mbenjamins schreef op dinsdag 24 september 2019 @ 19:16:
[...]


Momenteel gebruik ik de Laravel Debugbar, is het handig om over te gaan naar Laravel Telescope Toolbar?
Is het beter om alle watchers van Laravel Telescope uit te zetten op productie?

Of je overstapt moet je zelf weten. Ik vind Telescope soms wel makkelijk als je veel in de achtergrond doet, en voor simpele error tracking.
Als je alles uitzet op productie kan je hem beter niet op productie gebruiken. Maar ik zou iig wel dingen als query, views en logs uitzetten ja.

[CH4OS]

* of je dit even in een nieuw topic wil zetten *

[ Voor 101% gewijzigd door Creepy op 15-02-2020 16:32 ]

[Creepy]

Het is in elk geval verstandig er even een los topic voor te maken die waarschuwing staat er niet voor niets.

[CH4OS]

Ah, ik vond het niet groot genoeg om in een apart topic mee te nemen, vandaar dat ik het even hier zette.

[Navi]

Iemand suggesties voor een goede laravel tool om via een GUI snel je models te kunnen bouwen?

Heb even gezocht en kwam uit op LaraAdmin, maar dat project lijkt dood, en eventueel Infyom Laravel Generator maar weet niet of dat exact is wat ik zoek.

Een simpele backend waarbij je zelf je models en velden in elkaar kunt klikken, relaties tussen models etc. (En waar je deze dan ook kunt beheren ala Laravel Nova)

[ Voor 7% gewijzigd door Navi op 18-02-2020 20:31 ]

[Chris7]

Navi schreef op dinsdag 18 februari 2020 @ 20:24:
Iemand suggesties voor een goede laravel tool om via een GUI snel je models te kunnen bouwen?

Heb even gezocht en kwam uit op LaraAdmin, maar dat project lijkt dood, en eventueel Infyom Laravel Generator maar weet niet of dat exact is wat ik zoek.

Een simpele backend waarbij je zelf je models en velden in elkaar kunt klikken, relaties tussen models etc. (En waar je deze dan ook kunt beheren ala Laravel Nova)

Het heeft geen GUI maar je zou eens naar Laravel Blueprint kunnen kijken. Daarmee kan je niet alleen models genereren, maar ook controllers, jobs, mailables en ik dacht zelfs tests.

[Saven]

Dit topic lijkt nogal dood, maar ik heb een vraagstuk

Ik heb een aantal queries die meerdere malen duplicated zijn. Zal weinig impact hebben op de performance, maar toch zoek ik liever een oplossing om het wat meer te stroomlijnen.

Situatieschets:
Een user behoort aan een (of meerdere) company, en de company_id wordt in de url meegestuurd.

Bijv:
- https://my.app/7w3rbsfkg3/dashboard
- https://my.app/7w3rbsfkg3/invoices/list
- https://my.app/7w3rbsfkg3/articles/1/edit

* 7w3rbsfkg3 is een mini UUID als primary key (id) voor Company

Nu moet ik dus in elk request altijd het Company object ophalen en checken of de user toegang heeft tot deze Company. Ook moet ik aan de hand van de company_id uit de request meerdere malen op verschillende plekken het Company object ophalen:

• Middleware: check of Company uberhaupt bestaat -> haalt Company dus op en checken of user aan company is toegevoegd
• AppServiceProvider: View Composer haalt Company op en stuurt deze door naar parent view / layout.blade.php zodat ik overal in de view bij het Company object kan
• In een parent controller haal ik Company op, en sla ik op in $this->company = Company.. zodat ik niet in elke controller method de company weer moet ophalen maar makkelijk naar $this->company kan refereren

En volgens mij vergeet ik nog een plek. Maar je snapt denk ik wat ik bedoel. Dit moet toch beter kunnen? Dit zijn namelijk 3 identieke querys:

PHP:

Company::findOrFail( $request->company_id );

Iemand een suggestie of best practice?

[r-v]

Volgens mij zou je in je middleware de opgehaalde Company al toe kunnen wijzen aan het bestaande request, welke dan in alle vervolgstappen (controllers) ook beschikbaar is.

PHP:

public function handle($request, Closure $next)
{
    $company = Company::findOrFail( $request->company_id );

    $request->merge(['company' => $company]);

    return $next($request);
}

[ Voor 4% gewijzigd door r-v op 30-06-2020 16:27 ]

[Saven]

r-v schreef op dinsdag 30 juni 2020 @ 16:26:
Volgens mij zou je in je middleware de opgehaalde Company al toe kunnen wijzen aan het bestaande request, welke dan in alle vervolgstappen (controllers) ook beschikbaar is.

PHP:

public function handle($request, Closure $next)
{
    $company = Company::findOrFail( $request->company_id );

    $request->merge(['company' => $company]);

    return $next($request);
}

Hmm, dat lijkt idd te werken, thanks Ik vraag me echter wel af of dit een clean oplossing is, aangezien je hiermee het hele object in de request verwerkt. Raar dat hier geen best practice voor lijkt te zijn. Maar dat is meer een gevoel

Edit ik ben ook iets tegengekomen als dit:

PHP:

app()->instance('Company', $company);

Die in de middleware geplaatst kan worden.

Alleen is

PHP:

resolve('Company');

Niet beschikbaar in de controller constructor omdat de middleware sinds een aantal versies pas na de constructors wordt uitgevoerd.

[ Voor 18% gewijzigd door Saven op 30-06-2020 16:53 ]

[r-v]

Je kan dit overigens ook oplossen met Route model binding

[Saven]

r-v schreef op dinsdag 30 juni 2020 @ 16:53:
Je kan dit overigens ook oplossen met Route model binding

Top Dat lijkt idd te werken. Moet wat stukken herschrijven maar maakt het wel logischer.

Enige waar ik tegen aanloop is dat bijvoorbeeld in middleware of custom functies, je alsnog via

code:

request('company')

moet ophalen omdat je daar logischerwijs geen dependency injection hebt.

[TJVB]

Saven schreef op dinsdag 30 juni 2020 @ 17:55:
[...]

Enige waar ik tegen aanloop is dat bijvoorbeeld in middleware of custom functies, je alsnog via

code:

request('company')

moet ophalen omdat je daar logischerwijs geen dependency injection hebt.

In je middleware (afhankelijk van de volgorde van je middleware) kun je ook $request->company doen om je object te krijgen. Tenminste indien die door middel van modelbinding is opgehaald.

[Saven]

r-v schreef op dinsdag 30 juni 2020 @ 16:53:
Je kan dit overigens ook oplossen met Route model binding

TJVB schreef op donderdag 2 juli 2020 @ 09:59:
[...]


In je middleware (afhankelijk van de volgorde van je middleware) kun je ook $request->company doen om je object te krijgen. Tenminste indien die door middel van modelbinding is opgehaald.

Nou de kogel is (bijna?) door de kerk Ik ben overgens geen Laravel expert, dus het is allemaal nog wat nieuwig. Maar ik heb het nu opgelost, vraag me af wat jullie daar van vinden.

Route model binding was toch niet helemaal wat ik zocht. Want ik moet in élke controller method Company $company injecteren:

PHP:

    public function index(Request $request, Company $company)
    {
        //--------------------------------------------------
        // Set user's last logged in company id, for redirect to company dashboard after login
        //--------------------------------------------------
        Auth::user()->setLastCompanyLogin( $company->id );

        //--------------------------------------------------
        // Return view
        //--------------------------------------------------
        $view = view('dashboard.index');

        $view->with('me', Auth::user());

        return $view;
    }

Anders ziet de middleware

PHP:

    public function handle($request, Closure $next)
    {
        $company = $request->company;
        
        if (Auth::check() && !$company->hasUser(Auth::user()->id) && !Auth::user()->is_admin)
        {
            abort(403);
        }

        return $next($request);
    }

Het stukje

PHP:

$company = $request->company

als url string (bijv. a7xfnw49 uit https://my.app/a7xfnw49/dashboard) en niet als het Company object. Dat leek me nogal gevoelig voor fouten.

Dus... Ik heb nu een (deferred) CompanyServiceProvider gemaakt met een singleton bind. Als het goed is wordt die alleen uitgevoerd als ik app()->make() aanroep. In dat geval is de request('company') altijd aanwezig.

PHP:

class CompanyServiceProvider extends ServiceProvider implements DeferrableProvider
{
    public function register()
    {
        //
        $this->app->singleton(Company::class, function($app)
        {
            return Company::findOrFail(request('company'));
        });
    }

    public function provides()
    {
        return [Company::class];
    }
}

In kleine controllers roep ik het object aan via app()->make

PHP:

class DashboardController extends Controller
{
    public function index(Request $request)
    {
        $company = app()->make(Company::class);

        Auth::user()->setLastCompanyLogin( $company->id );

        //--------------------------------------------------
        // Return view
        //--------------------------------------------------
        $view = view('dashboard.index');

        $view->with('me', Auth::user());

        return $view;
    }
}

En in grote controllers gooi ik een $this->company in de controller constructor

PHP:

class SomeLargeController
{
    public function __construct(Request $request)
    {      
        $this->company = app()->make(Company::class);
    }

    public function view(Request $request)
    {      
        return view('invoices.list', ['company' => $this->company]);
    }

    // Much more..
}

En tot slot in de middleware

PHP:

    public function handle($request, Closure $next)
    {
        $company = app()->make(Company::class);

        if (Auth::check() && !$company->hasUser(Auth::user()->id) && !Auth::user()->is_admin)
        {
            abort(403);
        }

        return $next($request);
    }

Of ben ik nu echt debiel aan het doen en snap ik er geen snars van

[HollowGamer]

Heb je ook explicit binding geprobeerd? Die moet je namelijk hebben als je deze ook wilt aanroepen in iedere middleware als ik mij niet vergist.

[Saven]

Topic is helaas een beetje dood Toch probeer ik 't nog eens nieuw leven in te blazen met een vraag .

M'n applicatie gaat webhooks van een externe service ontvangen. Dat zijn meerdere type webhooks zoals:
- Wanneer een user is aangemaakt bij de externe service
- Wanneer een order is aangemaakt bij de externe service
- Wanneer een item is toegevoegd bij de externe service
etc. etc.

Het kan om best hoge volumes gaan en resource intensieve acties. Die webhooks wil je dus niet volledig verwerken bij het eerste request, maar in een wachtrij (queue) dumpen om later in batches te verwerken, zodat je server niet plat gaat van al die webhooks.

Bij andere projecten/applicaties (non-laravel) werkten we in feite met een grote Webhook_Queue database table en voor alle specifieke acties draaide er elke X minuten een cron die een X aantal webhooks verwerkte. De webhook receiver gooide simpelweg de payload en 'actie_type' in de database, en de crons pikten aan de hand van het actie_type ieder hun eigen payloads eruit om te verwerken.

Dat lijkt me voor Laravel niet de mooiste oplossing, zeker omdat de task scheduler daar imo niet voor bedoeld is. Iemand toevallig een best practice?

Ik zit er aan te denken om in de 'webhook receiver' te bepalen wat er precies uitgevoerd moet worden, en daarvoor een Job te starten. Dan krijg je dus een shitload aan jobs, (zeker wanneer iemand bijv. een import van 100.000 items doet bij de externe service, en ik dus 100.000 webhooks ontvang).

[TwArbo]

Saven schreef op donderdag 23 juli 2020 @ 12:54:
Topic is helaas een beetje dood Toch probeer ik 't nog eens nieuw leven in te blazen met een vraag .

M'n applicatie gaat webhooks van een externe service ontvangen. Dat zijn meerdere type webhooks zoals:
- Wanneer een user is aangemaakt bij de externe service
- Wanneer een order is aangemaakt bij de externe service
- Wanneer een item is toegevoegd bij de externe service
etc. etc.

Het kan om best hoge volumes gaan en resource intensieve acties. Die webhooks wil je dus niet volledig verwerken bij het eerste request, maar in een wachtrij (queue) dumpen om later in batches te verwerken, zodat je server niet plat gaat van al die webhooks.

Bij andere projecten/applicaties (non-laravel) werkten we in feite met een grote Webhook_Queue database table en voor alle specifieke acties draaide er elke X minuten een cron die een X aantal webhooks verwerkte. De webhook receiver gooide simpelweg de payload en 'actie_type' in de database, en de crons pikten aan de hand van het actie_type ieder hun eigen payloads eruit om te verwerken.

Dat lijkt me voor Laravel niet de mooiste oplossing, zeker omdat de task scheduler daar imo niet voor bedoeld is. Iemand toevallig een best practice?

Ik zit er aan te denken om in de 'webhook receiver' te bepalen wat er precies uitgevoerd moet worden, en daarvoor een Job te starten. Dan krijg je dus een shitload aan jobs, (zeker wanneer iemand bijv. een import van 100.000 items doet bij de externe service, en ik dus 100.000 webhooks ontvang).

Vermoed van wel, maar zeg het toch even. Hier al gekeken? https://laravel.com/docs/7.x/queues Je plaatst de jobs in de queue met payload en zet één of meerdere workers op die de boel verwerkt. https://laravel.com/docs/7.x/queues#running-the-queue-worker

[ Voor 4% gewijzigd door TwArbo op 23-07-2020 12:59 ]

[Saven]

TwArbo schreef op donderdag 23 juli 2020 @ 12:57:
[...]


Vermoed van wel, maar zeg het toch even. Hier al gekeken? https://laravel.com/docs/7.x/queues Je plaatst de jobs in de queue met payload en zet één of meerdere workers op die de boel verwerkt. https://laravel.com/docs/7.x/queues#running-the-queue-worker

Uiteraard Dat is een beetje wat ik er van maak met mijn idee voor het aanmaken van de Jobs per actie toch? Of begrijp ik je niet goed?

Edit: je had m net aangepast voordat ik commente maar idd

[ Voor 6% gewijzigd door Saven op 23-07-2020 13:50 ]

[TwArbo]

Saven schreef op donderdag 23 juli 2020 @ 13:48:
[...]

Uiteraard Dat is een beetje wat ik er van maak met mijn idee voor het aanmaken van de Jobs per actie toch? Of begrijp ik je niet goed?

Edit: je had m net aangepast voordat ik commente maar idd

Inderdaad een job per webhook request. De jobs worden in een queue gezet en dan een aparte worker instance opzetten om de boel te verwerken. De queues kun je inrichten zoals jij dat wilt. En wellicht kun je Laravel Horizon gebruiken; https://github.com/laravel/horizon / https://laravel.com/docs/7.x/horizon.

[ Voor 5% gewijzigd door TwArbo op 23-07-2020 13:54 ]

[PainkillA]

Laravel is op een aantal vlakken toch echt zeer vervelend in gebruik en het is dan gewoon niet mogelijk om mooie SOLID code te schrijven. Voorbeeld, stel je wil een custom validation rule maken die validatie parameter nodig heeft en een aantal externe services gebruikt die nodig zijn bij de validatie en wellicht een scalar value. Als je dit op een goede manier wil doen dan wil je de services en scalar values netjes injecteren in de constructor van de Rule.

hoe wil je dit het liefst gebruiken:

code:

`'someField' => 'required|string|MyCustomRule:someParameter'`

Deze setup is volstrekt onmogelijk en laravel wil graag dat je het als volgt doet:

code:

`'someField' => ['required','string', new MyCustomRule('someParameter')]

Dit werkt maar het is nu onmogelijk om op een nette manier aan de dependencies te komen. Je bent dus verplicht om je Rule vol te plemen met allemaal service locator calls direct op de globale ServiceContainer en de scalar moet je hardcoded direct uit een of andere config vissen. Waarom heeft laravel niet simpelweg een systeem gemaakt waarij je een Rule kan registreren op de validator zodat dit soort hacky setups niet gemaakt hoeven worden? Dit is 1 voorbeeld maar laravel zit vol met werkwijzen die elke best practise te buiten gaan en alleen leuk zijn als je een simpel "my first blog" projectje opzet

[Voutloos]

Het klopt dat Laravel tegen gaat werken als je niet alles heel magisch a la Taylor doet...
Maar wil je niet te veel in een validator? Weet je zeker dat je het niet in de controller wil doen? Externe services aanroepen in een validator klinkt ook niet per se ideaal.

[ Voor 3% gewijzigd door Voutloos op 23-07-2020 23:04 ]

[Barryvdh]

PainkillA schreef op donderdag 23 juli 2020 @ 15:48:
Laravel is op een aantal vlakken toch echt zeer vervelend in gebruik en het is dan gewoon niet mogelijk om mooie SOLID code te schrijven. Voorbeeld, stel je wil een custom validation rule maken die validatie parameter nodig heeft en een aantal externe services gebruikt die nodig zijn bij de validatie en wellicht een scalar value. Als je dit op een goede manier wil doen dan wil je de services en scalar values netjes injecteren in de constructor van de Rule.

hoe wil je dit het liefst gebruiken:

code:

`'someField' => 'required|string|MyCustomRule:someParameter'`

Deze setup is volstrekt onmogelijk en laravel wil graag dat je het als volgt doet:

code:

`'someField' => ['required','string', new MyCustomRule('someParameter')]

Dit werkt maar het is nu onmogelijk om op een nette manier aan de dependencies te komen. Je bent dus verplicht om je Rule vol te plemen met allemaal service locator calls direct op de globale ServiceContainer en de scalar moet je hardcoded direct uit een of andere config vissen. Waarom heeft laravel niet simpelweg een systeem gemaakt waarij je een Rule kan registreren op de validator zodat dit soort hacky setups niet gemaakt hoeven worden? Dit is 1 voorbeeld maar laravel zit vol met werkwijzen die elke best practise te buiten gaan en alleen leuk zijn als je een simpel "my first blog" projectje opzet

Je kan zoiets doen toch?

PHP:

class MyCustomRule {
  function validate($parameter) {
    return $parameter === 'someParameter';
  }
}
Validator::extend('MyCustomRule', function ($attribute, $value, $parameters, $validator) {
    return app(MyCustomRule::class)->validate(...$parameters);
});


Route::get('/', function (){
   $validator = Validator::make([
     'someField' => 'test',
   ], [
    'someField' => 'required|string|MyCustomRule:someParameter',
  ]);

  dump($validator->fails());

  return 'ok';
});

https://laravelplayground...24-420a-8896-967e8d8a6034

[PainkillA]

Barryvdh schreef op vrijdag 24 juli 2020 @ 09:56:
[...]


Je kan zoiets doen toch?

PHP:

class MyCustomRule {
  function validate($parameter) {
    return $parameter === 'someParameter';
  }
}
Validator::extend('MyCustomRule', function ($attribute, $value, $parameters, $validator) {
    return app(MyCustomRule::class)->validate(...$parameters);
});


Route::get('/', function (){
   $validator = Validator::make([
     'someField' => 'test',
   ], [
    'someField' => 'required|string|MyCustomRule:someParameter',
  ]);

  dump($validator->fails());

  return 'ok';
});

https://laravelplayground...24-420a-8896-967e8d8a6034

Dat werkt tot op zekere hoogte. De validatie zal slagen maar custom error messages via de 'message()' functie welke op de Rule interface zit worden dan genegeerd omdat laravel alleen de validate functie doorlust naar de Rule en de message call niet

[Barryvdh]

PainkillA schreef op vrijdag 24 juli 2020 @ 12:37:
[...]


Dat werkt tot op zekere hoogte. De validatie zal slagen maar custom error messages via de 'message()' functie welke op de Rule interface zit worden dan genegeerd omdat laravel alleen de validate functie doorlust naar de Rule en de message call niet

Ahja, dan zal je inderdaad toch een Rule object kunnen gebruiken. Taylor geeft aan dat hij daar (nu) geen plannen voor heeft inderdaad: https://github.com/larave...93#issuecomment-542684482

I think this has come up before but it's really not necessary and add's unnecessary complication.

You can resolve the rule from the container when you specify the rules:

'field' => [app(RuleClass::class)],

Dus als je daar een parameter bij wil kan je natuurlijk gewoon iets doen als:

PHP:

'field' => [app(RuleClass::class)->setParam('value')],

Wellicht inderdaad niet het mooiste, maar weet inderdaad ook niet hoevaak je zoiets doet. Je HOEFT niet alles in een validator te stoppen natuurlijk.

[amphora]

Bestaat er een Nederlandse laravel community? En dan bij voorkeur met wat freelancers waar ik af en toe mee kan sparren en elkaar eventueel helpen met projecten in tijden van drukte of vakanties. Heb genoeg wordpressers in m'n netwerk of junior php-ers maar die kunnen mij over het algemeen niet helpen. Ben zelf ook freelancer en bij vrijwel alle webprojecten neem ik laravel als basis.

[Barryvdh]

amphora schreef op vrijdag 24 juli 2020 @ 13:33:
Bestaat er een Nederlandse laravel community? En dan bij voorkeur met wat freelancers waar ik af en toe mee kan sparren en elkaar eventueel helpen met projecten in tijden van drukte of vakanties. Heb genoeg wordpressers in m'n netwerk of junior php-ers maar die kunnen mij over het algemeen niet helpen. Ben zelf ook freelancer en bij vrijwel alle webprojecten neem ik laravel als basis.

Er is een #laravel kanaal op de phpnl Slack. https://phpnl.nl/
En een LaraBeNe Slack: https://larabene.com/gids/slack

[Matis]

Barryvdh schreef op zaterdag 25 juli 2020 @ 11:53:
Er is een #laravel kanaal op de phpnl Slack. https://phpnl.nl/
En een LaraBeNe Slack: https://larabene.com/gids/slack

Bedankt voor de tip. Kende ze niet.

Gefeliciteerd nog

[Luc45]

Er is zojuist een security patch voor Laravel 6.x en 7.x uitgekomen.

Today we released a security patch for Laravel 6.x and 7.x.

In previous releases of Laravel, it was possible to mass assign Eloquent attributes that included the model's table name:

$model->fill(['users.name' => 'Taylor']);
When doing so, Eloquent would remove the table name from the attribute for you. This was a "convenience" feature of Eloquent and was not documented.

However, when paired with validation, this can lead to unexpected and unvalidated values being saved to the database. For this reason, we have removed the automatic stripping of table names from mass-asignment operaitons so that the attributes go through the typical "fillable" / "guarded" logic. Any attributes containing table names that are not explicitly declared as fillable will be discarded.

This security release will be a breaking change for applications that were relying on the undocumented table name stripping during mass assignment. Since this feature was relatively unknown and undocumented, we expect the vast majority of Laravel applications to be able to upgrade without issues.

https://blog.laravel.com/security-release-laravel-61834-7232

[Saven]

Waar ik niet helemaal uitkom met nested relations is bijv. het volgende. Een Company kan een aantal modules hebben, en die modules hebben ieder 1 settings tabel voor soort van metadata van de module voor die specifieke Company:

PHP:

$module = $company->modules()->where('name', 'Test Module')->first();
$settings = $module->settings;

$module geeft als query (ongeveer)

SQL:

SELECT * FROM modules WHERE modules.name = 'Test Module' and modules.company_id = 1234 LIMIT 1

Maar $settings negeert nu dat ik de module settings van de company wil:

SQL:

SELECT * FROM module_settings WHERE module_settings.module_id = 1 LIMIT 1

De eerste query haalt de results op van de specifieke Company. Maar de tweede query negeert de Company id volledig en haalt alleen de (een willekeurige, eerste) relatie op van een globale module. Die settings kunnen dus ook van een andere Company zijn.

Kan wel iets schrijven als

PHP:

$module = $company->modules()->where('name', 'Test Module')->first();
$settings = $module->settings()->where('company_id', 1234)->first();

maar dat vind ik ook weer niet zo sjiek ofzo. Is dat echt de enige manier in Laravel?

[patricks8]

Je zou in de settings relatie van je module een where statement kunnen toevoegen.

[Saven]

patricks8 schreef op donderdag 13 augustus 2020 @ 18:59:
Je zou in de settings relatie van je module een where statement kunnen toevoegen.

Maar hoe kom ik in die method aan de Company id? Dat is namelijk de uitdaging, ik probeer een 'parent relation' waarde te bepalen. Maar ik zie niet in hoe je die in een Eloquent model kunt opvragen?

Edit: je hebt me wel aan t denken gezet Heb nu het volgende en dat lijkt te werken Dus niet vanuit de Module model, maar vanuit de Company model.

PHP:

    // Company Model -> modules -> ..
    public function modules()
    {
        return $this->belongsToMany('App\Domain\Module\Module')
            ->withPivot('active', 'canceled')
            ->with(['settings' => function ($query)
            {
                $query->where('company_id', $this->id); //verbaasde me dat ik $this kan aanroepen in een functie..
                $query->limit(1);
            }]);
    }

[ Voor 43% gewijzigd door Saven op 13-08-2020 19:44 ]

[patricks8]

Saven schreef op donderdag 13 augustus 2020 @ 19:34:
[...]

Maar hoe kom ik in die method aan de Company id? Dat is namelijk de uitdaging, ik probeer een 'parent relation' waarde te bepalen. Maar ik zie niet in hoe je die in een Eloquent model kunt opvragen?

Edit: je hebt me wel aan t denken gezet Heb nu het volgende en dat lijkt te werken Dus niet vanuit de Module model, maar vanuit de Company model.

PHP:

    // Company Model -> modules -> ..
    public function modules()
    {
        return $this->belongsToMany('App\Domain\Module\Module')
            ->withPivot('active', 'canceled')
            ->with(['settings' => function ($query)
            {
                $query->where('company_id', $this->id); //verbaasde me dat ik $this kan aanroepen in een functie..
                $query->limit(1);
            }]);
    }

Ik heb zo geen pc bij de hand, maar als het goed is zou je company_id van je module moeten kunnen gebruiken. Als relatie krijg je dan

code:

public function settings() {
    return $this->hasMany(Setting::class)
        ->where(‘company_id’, $this->company_id);
}

Persoonlijk zou ik de relatie die jij hebt gedaan niet op deze manier gebruiken. Je kan ook vanuit je company model een HasManyThrough relatie kunnen doen voor de settings. Hier heb ik alleen geen ervaring mee.

[ Voor 8% gewijzigd door patricks8 op 13-08-2020 20:07 ]

[Saven]

patricks8 schreef op donderdag 13 augustus 2020 @ 20:02:
[...]


Ik heb zo geen pc bij de hand, maar als het goed is zou je company_id van je module moeten kunnen gebruiken. Als relatie krijg je dan

code:

public function settings() {
    return $this->hasMany(Setting::class)
        ->where(‘company_id’, $this->company_id);
}

Persoonlijk zou ik de relatie die jij hebt gedaan niet op deze manier gebruiken. Je kan ook vanuit je company model een HasManyThrough relatie kunnen doen voor de settings. Hier heb ik alleen geen ervaring mee.

Snap ik idd Persoonlijk vind ik dit nog wel een nette oplossing gezien de situatie, het probleem is namelijk dat de situatie er ong zo uitziet:

De module_settings hoort bij zowel een Company als een Module: en via een company_module pivot table worden de modules aan de company gehangen. Elke company heeft zijn eigen module_settings voor een specifieke module.

Company
id, name, created_at
1, Testcompany, 2020-01-01

Modules
id, name
1, Template
2, Shipping
3, Products

company_module
id, company_id, module_id
1, 1, 1
2, 1, 2

module_settings
id, module_id, shop_id, api_key, api_secret, api_endpoint, etc, etc

Volgens mij is het ook wel een beetje exotisch wat ik heb, want ik kon eigenlijk niet zoiets vinden in de Laravel docs. Het hele ORM gedeelte is eigenlijk gebaseerd op een relatie met één key, ook de HasThrough volgens mij. De module_settings krijg ik dus niet op een makkelijkere manier gekoppeld

[basvaningen]

Ik ben sinds een tijd mij aan het verdiepen in Laravel i.c.m. Vue SPA en wil hier een klein projectje mee gaan maken. Echter na heeeeeel veel googlen kom ik uit 1 ding niet uit:
Authentication!!!

Wat is de "beste" manier hiervoor. Laravel Passport gebruiken of JWT?
Ik heb een aantal youtube video's gezien die het ook "handmatig" doen en dan de Auth:: facade gebruiken.

Wat zijn jullie tips?

[PatrickH89]

basvaningen schreef op zaterdag 22 augustus 2020 @ 17:10:
Ik ben sinds een tijd mij aan het verdiepen in Laravel i.c.m. Vue SPA en wil hier een klein projectje mee gaan maken. Echter na heeeeeel veel googlen kom ik uit 1 ding niet uit:
Authentication!!!

Wat is de "beste" manier hiervoor. Laravel Passport gebruiken of JWT?
Ik heb een aantal youtube video's gezien die het ook "handmatig" doen en dan de Auth:: facade gebruiken.

Wat zijn jullie tips?

Laravel Sanctum is waarschijnlijk het makkelijkst. Zitten je frontend en backend op hetzelfde domein? Dan kun je de standaard auth van Sanctum gebruiken, anders voor de andere oplossing gaan (zie 'for mobile apps' oid in de documentatie).

[basvaningen]

Heb mijzelf eens verdiept in Sanctum en een aardige mooie uitleg kunnen halen uit deze video
YouTube: #1: SPA Authentication using Laravel Sanctum (formerly Laravel Airlock)

[Chris7]

basvaningen schreef op zaterdag 22 augustus 2020 @ 17:10:
Ik ben sinds een tijd mij aan het verdiepen in Laravel i.c.m. Vue SPA en wil hier een klein projectje mee gaan maken.

Niet precies waar je naar op zoek bent, maar waarschijnlijk wel interessant: kijk eens naar Inertia.js. Dit is een wat andere manier om SPA's te maken: Alle routes zijn serverside en je hebt geen API. In plaats daarvan rendert Laravel de Inertia view (en dat kan dan een Vue, React of Svelte SPA zijn). Het stukje JS van Inertia zorgt er dan vervolgens voor dat je aan de voorkant geen harde refresh krijgt maar meer de ervaring zoals je die hebt bij een normale SPA.

Ben er nu zelf een klein projectje mee aan het maken en het bevalt uitstekend. Ik vind het zelf vaak veel werk om een API te maken die dan alleen door je eigen frontend wordt geconsumeerd. Met Inertia werk je meer op een traditionele manier (serverside views) maar heb je wel de SPA ervaring.

[basvaningen]

@Chris7 Bedankt voor de tip! Ziet er goed uit, ik ga er naar kijken!

[Hiroj]

Ik ben erg benieuwd wie van jullie Laracon Online heeft gevolgd afgelopen woensdag. Zelf keek ik tot aan de presentatie van Taylor Otwell, waar ik eigenlijk enkel echt voor keek. Al mag gezegd worden dat de talk van Jenny Shen ook zeer interessant was!

Laravel 8 brengt een aantal mooie nieuwe features voor ontwikkelaars. Vooral de Batched Jobs implementatie zag er behoorlijk goed uit!

Wat vonden jullie van Laracon Online?

[Barryvdh]

Hiroj schreef op vrijdag 28 augustus 2020 @ 10:40:
Ik ben erg benieuwd wie van jullie Laracon Online heeft gevolgd afgelopen woensdag. Zelf keek ik tot aan de presentatie van Taylor Otwell, waar ik eigenlijk enkel echt voor keek. Al mag gezegd worden dat de talk van Jenny Shen ook zeer interessant was!

Laravel 8 brengt een aantal mooie nieuwe features voor ontwikkelaars. Vooral de Batched Jobs implementatie zag er behoorlijk goed uit!

Wat vonden jullie van Laracon Online?

Ik heb die van Taylor grotendeels gezien, en die over Inertia van Jonathan Reinink. Die van Jenny had ik volgens mij in 2018 al live gezien. Volgens mij staan ze nu online, dus wellicht van het weekend nog even die van Jack Ellis over Fathom en Caleb over Livewire terugkijken.

[Hiroj]

Barryvdh schreef op vrijdag 28 augustus 2020 @ 12:58:
[...]


Ik heb die van Taylor grotendeels gezien, en die over Inertia van Jonathan Reinink. Die van Jenny had ik volgens mij in 2018 al live gezien. Volgens mij staan ze nu online, dus wellicht van het weekend nog even die van Jack Ellis over Fathom en Caleb over Livewire terugkijken.

Ik ben sowieso wel geïnteresseerd om Inertia en/of LiveWire te gebruiken voor een toekomstig project. Zijn beide fantastische toevoegingen aan het framework.

Heb je Laravel JetStream nog meegekregen? Daar ben ik ook wel enthousiast over.

[ Voor 9% gewijzigd door Hiroj op 28-08-2020 16:21 ]

[Barryvdh]

Hiroj schreef op vrijdag 28 augustus 2020 @ 16:21:
[...]


Ik ben sowieso wel geïnteresseerd om Inertia en/of LiveWire te gebruiken voor een toekomstig project. Zijn beide fantastische toevoegingen aan het framework.

Heb je Laravel JetStream nog meegekregen? Daar ben ik ook wel enthousiast over.

Ja ben ook wel benieuwd. Zag er goed uit, en zeker benieuwd hoe Taylor dat zou opzetten. Is altijd alleen maar de vraag hoe uitbreidbaar het is, maar zag er goed uit.

LiveWire klinkt allemaal wel goed, maar moet nog keer goed project vinden om te testen. Tailwind is ook nog kwestie van wennen denk ik..

[Marc3l]

Hiroj schreef op vrijdag 28 augustus 2020 @ 10:40:
Ik ben erg benieuwd wie van jullie Laracon Online heeft gevolgd afgelopen woensdag. Zelf keek ik tot aan de presentatie van Taylor Otwell, waar ik eigenlijk enkel echt voor keek. Al mag gezegd worden dat de talk van Jenny Shen ook zeer interessant was!

Laravel 8 brengt een aantal mooie nieuwe features voor ontwikkelaars. Vooral de Batched Jobs implementatie zag er behoorlijk goed uit!

Wat vonden jullie van Laracon Online?

Heb precies ook tot die van Taylor gekeken. JetStream vond ik zeer interessant.
Feature dat je je migrations kan mergen tot een sql dump vond ik wel tricky. Je moet dan wel zeker weten dat al je migration files op productie zijn doorgevoerd.

Van de week even wat video's terugkijken

[Hiroj]

Barryvdh schreef op vrijdag 28 augustus 2020 @ 16:46:
[...]


Ja ben ook wel benieuwd. Zag er goed uit, en zeker benieuwd hoe Taylor dat zou opzetten. Is altijd alleen maar de vraag hoe uitbreidbaar het is, maar zag er goed uit.

LiveWire klinkt allemaal wel goed, maar moet nog keer goed project vinden om te testen. Tailwind is ook nog kwestie van wennen denk ik..

Ik snap ook nog steeds niet waarom iedereen zo enthousiast wordt van TailwindCSS. Al die "utility classes" die je dan op je HTML moet knallen vind ik maar niks.

Ik heb wel een leuk project waarmee ik eens goed TailwindCSS en Livewire kan uitproberen. Ben benieuwd wat ik er uiteindelijk van ga vinden.

Marc3l schreef op vrijdag 28 augustus 2020 @ 17:55:
[...]

Heb precies ook tot die van Taylor gekeken. JetStream vond ik zeer interessant.
Feature dat je je migrations kan mergen tot een sql dump vond ik wel tricky. Je moet dan wel zeker weten dat al je migration files op productie zijn doorgevoerd.

Van de week even wat video's terugkijken

Die schema:dump commando werd ook aangeprezen, wanneer je het voor je lokale development environment zou gebruiken. Ik snap dan niet helemaal waarom je zo'n commando maakt. Mijn klanten hebben talloze projecten overgedragen, waarbij je door al die migration files het bos niet meer ziet.

[Chris7]

Hiroj schreef op maandag 31 augustus 2020 @ 13:00:
[...]

Ik snap ook nog steeds niet waarom iedereen zo enthousiast wordt van TailwindCSS. Al die "utility classes" die je dan op je HTML moet knallen vind ik maar niks.

Ik heb wel een leuk project waarmee ik eens goed TailwindCSS en Livewire kan uitproberen. Ben benieuwd wat ik er uiteindelijk van ga vinden.

Misschien licht off-topic voor een Laravel thread, maar ik gebruik Tailwind nu al een aantal jaar op projecten en wil niet meer terug. Ja, je HTML zit vol met classes, maar als je een wijziging wil maken dan kan je dat ter plekke doen, in plaats van heen en weer te gaan tussen je template en CSS files. Plus je leest in de HTML direct terug hoe de styling is.

Eigenlijk wordt dus je markup vooral lelijker, ik zou niet willen zeggen onoverzichtelijker, want als je een collectie classes hebt dan moet je ook in de CSS kijken wat voor styling die toepassen. En als je dan bv. een element van plek wil veranderen, moet je ook je CSS veranderen (met utility classes zit alles op 1 plek).

De kanttekening is wel dat Tailwind vooral werkt als je zelf de layout maakt. Als het design je niet zo veel uitmaakt, dan is iets als Bootstrap of Bulma met ready-to-go componenten misschien een betere keuze (alsnog zou ik zelf denk ik wel voor Tailwind kiezen, zeker nu ze met Tailwind UI ook een component library hebben).

[Hiroj]

Chris7 schreef op maandag 31 augustus 2020 @ 13:44:
[...]


Misschien licht off-topic voor een Laravel thread, maar ik gebruik Tailwind nu al een aantal jaar op projecten en wil niet meer terug. Ja, je HTML zit vol met classes, maar als je een wijziging wil maken dan kan je dat ter plekke doen, in plaats van heen en weer te gaan tussen je template en CSS files. Plus je leest in de HTML direct terug hoe de styling is.

Eigenlijk wordt dus je markup vooral lelijker, ik zou niet willen zeggen onoverzichtelijker, want als je een collectie classes hebt dan moet je ook in de CSS kijken wat voor styling die toepassen. En als je dan bv. een element van plek wil veranderen, moet je ook je CSS veranderen (met utility classes zit alles op 1 plek).

De kanttekening is wel dat Tailwind vooral werkt als je zelf de layout maakt. Als het design je niet zo veel uitmaakt, dan is iets als Bootstrap of Bulma met ready-to-go componenten misschien een betere keuze (alsnog zou ik zelf denk ik wel voor Tailwind kiezen, zeker nu ze met Tailwind UI ook een component library hebben).

Tailwind wil ik ook niet helemaal afschuiven, maar qua overzicht bewaren in een blade view is het wel erg lastig. Enige oplossing daarvoor die ik nu heb gezien (ook tijdens de talk) is dat je alle blokken in components transformeert.

Desalniettemin ga ik het eens proberen en kijken waar het mij brengt. Wie weet stap ik ook wel volledig over op TailwindCSS. Heb jij nog goede tips voor mij waar ik rekening mee moet houden?

[Chris7]

Hiroj schreef op dinsdag 1 september 2020 @ 10:06:
[...]

Tailwind wil ik ook niet helemaal afschuiven, maar qua overzicht bewaren in een blade view is het wel erg lastig. Enige oplossing daarvoor die ik nu heb gezien (ook tijdens de talk) is dat je alle blokken in components transformeert.

Desalniettemin ga ik het eens proberen en kijken waar het mij brengt. Wie weet stap ik ook wel volledig over op TailwindCSS. Heb jij nog goede tips voor mij waar ik rekening mee moet houden?

Overzicht vind ik zelf ook het grootste nadeel, maar dat weegt in mijn ogen niet op tegen de voordelen. Plus het dwingt je inderdaad eerder grote files op te breken in componenten.

- De documentatie is uitstekend. In het begin moet je soms nog opzoeken welke CSS properties mappen naar welke classes. Verder hebben ze ook een heel aantal screencasts voor als je dat een prettige manier van leren vindt.
- Gebruik PurgeCSS om bij een productie build alleen de classes over te houden die je gebruikt. Zit tegenwoordig ingebakken in Tailwind, zie docs.
- Omdat je bijna geen CSS meer schrijft vind ik een preprocessor zelf niet meer nodig, is weer een klein stukje complexiteit minder. Ik gebruik nu vanilla CSS, met in m'n laatste project wel een paar PostCSS plugins die in de Tailwind docs worden aangeraden (Tailwind is zelf ook al een PostCSS plugin).
- Tailwind UI is betaald maar heeft van veel componenten ook een gratis variant, en omdat het alleen utility classes gebruikt zijn die makkelijk te customizen. Aanrader alleen al om eens te kijken hoe de makers van het framework componenten opzetten.

[rnark]

Release day! Wat vinden jullie de meest interessante nieuwe feature in Laravel 8?

Persoonlijk vind ik Jetstream heel interessant. Maar de release zit eigenlijk vol met mooie nieuwe features.

[Postman]

Jetstream lijktleek me ook interessant, totdat ik zag dat je geforceerd word om Tailwind te gebruiken én npm te draaien.
Waarom weer zo ingewikkeld allemaal. Kan ik niet gewoon Jetstream met Bootstrap 4 blijven gebruiken? Google helpt me helaas niet, alleen maar Bootstrap bashing resultaten.

[Barryvdh]

Wat is er mis met NPM draaien?

Een Bootstrap variant heb ik nog niet gezien inderdaad, maar is wellicht niet zo spannend om te bouwen.

[Postman]

Barryvdh schreef op dinsdag 8 september 2020 @ 11:43:
Wat is er mis met NPM draaien?

Niets als je het ook daadwerkelijk gebruikt. Anders geeft het alleen nog maar meer overhead (deploy op een shared host, dus geen SSH).

Een Bootstrap variant heb ik nog niet gezien inderdaad, maar is wellicht niet zo spannend om te bouwen.

Heb het even geprobeerd en ook op Reddit was de conclusie dat het toch wel wat meer voeten in de aarde heeft dan een simpele aanpassing. Het is zo diep verweven dat CSS al aanzienlijk wat hoofdbrekens geeft, maar vooral de JavaScript vervolgens voor problemen zorgt.

Wellicht dat er Bootstrap UI zullen komen vanuit de community, maar nadeel daarvan is dat je moet afwachten of het bijgewerkt word. En de hele UI -auth optie lijkt de kant van deprecated op te gaan, het is al legacy genoemd in de release notes van 8.

Voor iemand die net een simpele blog heeft gemaakt in Laravel om te gebruiken in een website gemaakt met Bootstrap 4 (en waar het Laravel project dus compleet los van staat) zijn deze aankondigingen niet echt bemoedigend. Het is dat een shared host weinig opties biedt, anders was het een beetje de discussie over PHP in de coffee corner voor mij...

Waarom Laravel trouwens: omdat het een makkelijke en volgens mij goede manier geeft om login en registratie te doen. Een blog zou ik ook in plain PHP kunnen maken, alleen heel het security wiel opnieuw uitvinden zie ik niet zitten.

[Barryvdh]

Postman schreef op dinsdag 8 september 2020 @ 11:59:
[...]

Niets als je het ook daadwerkelijk gebruikt. Anders geeft het alleen nog maar meer overhead (deploy op een shared host, dus geen SSH).

Maar je kan toch lokaal bouwen en dan gewoon de gecompileerde bestanden committen en deployen?

[Postman]

Barryvdh schreef op dinsdag 8 september 2020 @ 12:09:
[...]


Maar je kan toch lokaal bouwen en dan gewoon de gecompileerde bestanden committen en deployen?

Vendor was al 6000+ bestanden met 49MB. Om nog meer troep te moeten uploaden zie ik niet zitten. En ja troep want ik gebruik het niet, heel de node_modules map is dus onzin voor mij en alleen omdat Jetstream het forceert.

Dus ik blijf maar bij UI met Bootstrap voorlopig en kijk wel of ze een update doen voor Jetstream. En anders misschien helemaal van Laravel afstappen, kijken wat er nog voor andere mogelijkheden zijn die security out of the box leveren.

[Barryvdh]

Postman schreef op dinsdag 8 september 2020 @ 12:36:
[...]

Vendor was al 6000+ bestanden met 49MB. Om nog meer troep te moeten uploaden zie ik niet zitten. En ja troep want ik gebruik het niet, heel de node_modules map is dus onzin voor mij en alleen omdat Jetstream het forceert.

Dus ik blijf maar bij UI met Bootstrap voorlopig en kijk wel of ze een update doen voor Jetstream. En anders misschien helemaal van Laravel afstappen, kijken wat er nog voor andere mogelijkheden zijn die security out of the box leveren.

Je vendor of node_modules hoef je ook niet te committen hè, tijdens een deploy doe je gewoon composer install. En je JavaScript en CSS bevatten alles in app.js/app.css normaal gesproken na compileren.

[amphora]

Barryvdh schreef op dinsdag 8 september 2020 @ 12:43:
[...]


Je vendor of node_modules hoef je ook niet te committen hè, tijdens een deploy doe je gewoon composer install. En je JavaScript en CSS bevatten alles in app.js/app.css normaal gesproken na compileren.

Voor composer install moet je wel SSH toegang hebben, en dat heeft hij niet (shared hosting).
Ik bouw ook regelmatig kleinere sites met Laravel maar als de klant alleen een FTP account aanlevert ga ik ze toch echt proberen te overtuigen om een andere hoster te zoeken (of ik zet het op één van m'n Forge servers)

[Chris7]

Als je geen SSH toegang hebt dan heb je /vendor inderdaad wel nodig, maar node_modules niet. Je kan de CSS en JS lokaal compileren en die dan mee committen. Ik doe dat voor sommige projecten omdat het deployen makkelijker maakt. Je hoeft dan niet in je CI te builden en dan de artifacts weer ergens heen sturen, of op je productie server Node te draaien. Een deploy is dan in feite een git pull en composer install. Een nadeel is wel dat je per ongeluk een niet-geoptimaliseerde build van CSS/JS kan committen.

[PatrickH89]

Chris7 schreef op dinsdag 8 september 2020 @ 15:02:
Als je geen SSH toegang hebt dan heb je /vendor inderdaad wel nodig, maar node_modules niet. Je kan de CSS en JS lokaal compileren en die dan mee committen. Ik doe dat voor sommige projecten omdat het deployen makkelijker maakt. Je hoeft dan niet in je CI te builden en dan de artifacts weer ergens heen sturen, of op je productie server Node te draaien. Een deploy is dan in feite een git pull en composer install. Een nadeel is wel dat je per ongeluk een niet-geoptimaliseerde build van CSS/JS kan committen.

Beter is dan een release te laten voorbereiden op je CI/CD platform zodat er gewoon ergens een zip geüpload en gedeployed kan worden dan. Het build proces draait alle commands die je nodig hebt (composer install, npm install, npm run production etc.) zodat je geen SSH toegang hoeft te hebben. Github, Bitbucket en Gitlab hebben allemaal en manier om te builden tegenwoordig, naast legio andere CI/CD tools.

[Postman]

Aangezien ik toch niet zo ver was de keuze gemaakt om te beginnen met de nieuwe Laravel 8 en Jetstream en kijken of ik die (zonder te worden) om kan zetten naar Bootstrap 4. Op die manier zou ik wel gebruik kunnen maken van de nieuwe back-end, en ook mijn huidige front-end makkelijk kunnen ondersteunen.

Over het deployen naar shared host: dat van de node_modules wist ik niet, goede tip. En ik ben inderdaad van plan het de volgende keer via een zip bestand te doen en deze dan op de server (via een PHP script ) uit te pakken en alles goed te zetten. Scheelt allicht in de tijd want al die kleine meuk via FTP gaat traag

offtopic:
Weet iemand nog een goede hosting die wel SSH heeft? Ik ben nu bij one.com en betaal daar eigenlijk vrij weinig voor best aardig wat, behalve dan de SSH. Iets meer per maand is geen probleem, mits het vergelijkbare specs zijn met toevoeging van SSH dus. Al gekeken en wat bijv. TransIP en Antagonist aanbieden is meteen fors duurder en ook minder qua hoeveelheid opslag/dataverbruik. Zelfs de irritante Strato kost een vermogen voor bijna niets.

[scosec]

Postman schreef op dinsdag 8 september 2020 @ 19:10:
Aangezien ik toch niet zo ver was de keuze gemaakt om te beginnen met de nieuwe Laravel 8 en Jetstream en kijken of ik die (zonder te worden) om kan zetten naar Bootstrap 4. Op die manier zou ik wel gebruik kunnen maken van de nieuwe back-end, en ook mijn huidige front-end makkelijk kunnen ondersteunen.

Over het deployen naar shared host: dat van de node_modules wist ik niet, goede tip. En ik ben inderdaad van plan het de volgende keer via een zip bestand te doen en deze dan op de server (via een PHP script ) uit te pakken en alles goed te zetten. Scheelt allicht in de tijd want al die kleine meuk via FTP gaat traag

offtopic:
Weet iemand nog een goede hosting die wel SSH heeft? Ik ben nu bij one.com en betaal daar eigenlijk vrij weinig voor best aardig wat, behalve dan de SSH. Iets meer per maand is geen probleem, mits het vergelijkbare specs zijn met toevoeging van SSH dus. Al gekeken en wat bijv. TransIP en Antagonist aanbieden is meteen fors duurder en ook minder qua hoeveelheid opslag/dataverbruik. Zelfs de irritante Strato kost een vermogen voor bijna niets.

Ik zit zelf bij neostrada. Tot op heden erg tevreden over. Goede snelheid en werkt met cpanel.

[Postman]

Altijd leuk hidden changes: https://github.com/laravel/ui/issues/138
Ik wou dus in Laravel 8 een nieuw project starten met de oude UI --auth oplossing. Dit werkt dus niet. Lijkt dus dat ze al heel UI deprecated hebben in favor van Jetstream (en zeg dus maar dag tegen Bootstrap).

Wat een bagger ontwikkelaars zeg...

[PainkillA]

Postman schreef op dinsdag 8 september 2020 @ 23:44:
Altijd leuk hidden changes: https://github.com/laravel/ui/issues/138
Ik wou dus in Laravel 8 een nieuw project starten met de oude UI --auth oplossing. Dit werkt dus niet. Lijkt dus dat ze al heel UI deprecated hebben in favor van Jetstream (en zeg dus maar dag tegen Bootstrap).

Wat een bagger ontwikkelaars zeg...

laravel blijft in heel veel opzichten nog in de startup fase, een super degelijk upgrade beleid met backwards compatibility promise zoals symfony dat wel heeft is enorm belangrijk voor professionele omgevingen.

Waar je bij symfony 6 maanden van tevoren al de aankomende wijzigingen weet en alvast deprecated calls makkelijk kan detecteren en wijzigen wordt er bij laravel een nieuwe versie over de schutting gegooid en moet je maar lekker de upgrade guide gaan doorspitten en alles aanpassen en hopen dat er niets is vergeten door team laravel.

Verder is laravel vooral bezig met flashy trendy features te bouwen ipv echt belangrijke zaken toe te voegen/wijzigen. Code architectuur komt bij laravel op plek 99, prio 1 is dat groene junior developers/of hobbyisten die nog nooit in php hebben gewerkt een (draak van een) applicatie moeten kunnen bouwen die doet wat het moet doen.

[Postman]

PainkillA schreef op woensdag 9 september 2020 @ 08:39:
laravel blijft in heel veel opzichten nog in de startup fase, een super degelijk upgrade beleid met backwards compatibility promise zoals symfony dat wel heeft is enorm belangrijk voor professionele omgevingen.

Waar je bij symfony 6 maanden van tevoren al de aankomende wijzigingen weet en alvast deprecated calls makkelijk kan detecteren en wijzigen wordt er bij laravel een nieuwe versie over de schutting gegooid en moet je maar lekker de upgrade guide gaan doorspitten en alles aanpassen en hopen dat er niets is vergeten door team laravel.

Verder is laravel vooral bezig met flashy trendy features te bouwen ipv echt belangrijke zaken toe te voegen/wijzigen. Code architectuur komt bij laravel op plek 99, prio 1 is dat groene junior developers/of hobbyisten die nog nooit in php hebben gewerkt een (draak van een) applicatie moeten kunnen bouwen die doet wat het moet doen.

Begin dat nu ook te merken en ik val eigenlijk voor Laravel onder de categorie groene junior developers.
Zie ook dat veel van Laravel op Symfony leunt, vraag me af of het in mijn geval niet beter zou zijn om daar wat tijd in te investeren en heel Laravel te laten varen.

Wat ik het meest storende vind is dat er sowieso breaking changes zijn (nog los van het ontbreken van uitleg hoe aan te passen of een omweg te gebruiken) en dat veel van die breaking changes niet eens gecommuniceerd worden. Nee die moet je maar tijdens productie ervaren.

Voor mij zit de kracht van Laravel in de simpele out of the box registratie, login en authenticatie en autorisatie. Als ik dat met bijvoorbeeld Symfony ook kan bereiken dan zou dat voor mij een oplossing zijn (Yii2 schijnt daar ook erg goed in te zijn, maar het is redelijk niche dus weinig tutorial te vinden).

[Barryvdh]

Postman schreef op dinsdag 8 september 2020 @ 23:44:
Altijd leuk hidden changes: https://github.com/laravel/ui/issues/138
Ik wou dus in Laravel 8 een nieuw project starten met de oude UI --auth oplossing. Dit werkt dus niet. Lijkt dus dat ze al heel UI deprecated hebben in favor van Jetstream (en zeg dus maar dag tegen Bootstrap).

Wat een bagger ontwikkelaars zeg...

De laravel/ui package werkt nog gewoon, je moet er alleen een namespace omheen zetten, als je geen default route namespace meer hebt. (Staat ook in het issue)

PainkillA schreef op woensdag 9 september 2020 @ 08:39:
[...]


laravel blijft in heel veel opzichten nog in de startup fase, een super degelijk upgrade beleid met backwards compatibility promise zoals symfony dat wel heeft is enorm belangrijk voor professionele omgevingen.

Waar je bij symfony 6 maanden van tevoren al de aankomende wijzigingen weet en alvast deprecated calls makkelijk kan detecteren en wijzigen wordt er bij laravel een nieuwe versie over de schutting gegooid en moet je maar lekker de upgrade guide gaan doorspitten en alles aanpassen en hopen dat er niets is vergeten door team laravel.

Verder is laravel vooral bezig met flashy trendy features te bouwen ipv echt belangrijke zaken toe te voegen/wijzigen. Code architectuur komt bij laravel op plek 99, prio 1 is dat groene junior developers/of hobbyisten die nog nooit in php hebben gewerkt een (draak van een) applicatie moeten kunnen bouwen die doet wat het moet doen.

Voor bestaande applicaties verandert er niks. Het enige dat veranderd is, is dat in NIEUWE applicaties de default namespace is weggehaald. In oude applicaties KAN je dat ook doen als je wil (kon eerst ook al). Als je dat doet moet je wel de oude Auth routes in een Route group zetten met die middleware inderdaad.

Daarnaast gaat dit om het opzetten van boilerplate code, niet het framework zelf. Je kan gewoon nog steeds laravel/ui gebruiken. Je kan ook de nieuws presets gebruiken, of gewoon je code zelf schrijven. En als laravel/ui straks niet meer werkt dan wordt er echt wel een community fork gemaakt (of je doet dat zelf).

[Postman]

Er is meer mis, waar zijn de controllers bijvoorbeeld gebleven? Worden wel netjes vermeld in de documentatie, echter in Jetstream bestaan ze totaal niet meer.

This command should be used on fresh applications and will install a layout view, registration and login views, as well as routes for all authentication end-points. A HomeController will also be generated to handle post-login requests to your application's dashboard.

[Barryvdh]

Postman schreef op woensdag 9 september 2020 @ 13:37:
Er is meer mis, waar zijn de controllers bijvoorbeeld gebleven? Worden wel netjes vermeld in de documentatie, echter in Jetstream bestaan ze totaal niet meer.

[...]

Met JetStream heb ik geen ervaring, maar zoals ik begreep zouden ze in je App/Http moeten gekopieerd moeten worden.

Voor laravel/ui heb ik een Pull Request ingediend om hem standaard te laten werken met Laravel 8: https://github.com/laravel/ui/pull/143

Edit: Ik heb het even bekeken, maar ze komen uit Fortify. Zie https://github.com/larave.../1.x/src/Http/Controllers
De templates worden wel gekopieerd zodat je ze kan aanpassen.

[ Voor 15% gewijzigd door Barryvdh op 09-09-2020 14:07 ]

[Chris7]

PatrickH89 schreef op dinsdag 8 september 2020 @ 16:20:
[...]
Beter is dan een release te laten voorbereiden op je CI/CD platform zodat er gewoon ergens een zip geüpload en gedeployed kan worden dan. Het build proces draait alle commands die je nodig hebt (composer install, npm install, npm run production etc.) zodat je geen SSH toegang hoeft te hebben. Github, Bitbucket en Gitlab hebben allemaal en manier om te builden tegenwoordig, naast legio andere CI/CD tools.

Ja, maar dan moet je dus een build ergens uploaden en daar vandaan kunnen deployen. Voor kleinere projecten vind ik het een prima oplossing om gecompileerde dependencies in te checken in Git. Bij een deploy hoef je dan alleen een bepaalde branch van git te pullen (met bijvoorbeeld Forge kan dat wel automatisch, de CI pingt Forge om z'n deploy script uit te voeren).

[PatrickH89]

Chris7 schreef op woensdag 9 september 2020 @ 15:04:
[...]


Ja, maar dan moet je dus een build ergens uploaden en daar vandaan kunnen deployen. Voor kleinere projecten vind ik het een prima oplossing om gecompileerde dependencies in te checken in Git. Bij een deploy hoef je dan alleen een bepaalde branch van git te pullen (met bijvoorbeeld Forge kan dat wel automatisch, de CI pingt Forge om z'n deploy script uit te voeren).

Je kunt een build tool als Github Actions, Bitbucket Pipelines etc ook gewoon laten deployen in plaats van die upload tussenstap. Ik snap dat het de eerste keer gedoe is om op te zetten, maar ik zou het kleinste project wat er bestaat niet meer op die manier deployen (echt waardeloos om zo'n vervuilde git repo te hebben). Er is natuurlijk op zich niet zoveel mis mee voor kleinere projecten, maar ik vind de workflow met CI/CD tool een stuk fijner.

[Saven]

amphora schreef op dinsdag 8 september 2020 @ 13:20:
[...]

Voor composer install moet je wel SSH toegang hebben, en dat heeft hij niet (shared hosting).
Ik bouw ook regelmatig kleinere sites met Laravel maar als de klant alleen een FTP account aanlevert ga ik ze toch echt proberen te overtuigen om een andere hoster te zoeken (of ik zet het op één van m'n Forge servers)

Commerciële pro tip: vraag gewoon 2 a 3 tientjes per maand aan je klanten voor hosting en knal 'm op een eigen vpsje. Geen gezeik, alles in eigen beheer, en backup automatisch in te stellen. Easy peasy. Makkelijk te verkopen ook hoor.

Als een klant wel betaalt voor een Laravel app maar niet fatsoenlijke hosting wil betalen lijkt me het sowieso geen fijne klant. Maar dat terzijde

[Barryvdh]

Postman schreef op dinsdag 8 september 2020 @ 23:44:
Altijd leuk hidden changes: https://github.com/laravel/ui/issues/138
Ik wou dus in Laravel 8 een nieuw project starten met de oude UI --auth oplossing. Dit werkt dus niet. Lijkt dus dat ze al heel UI deprecated hebben in favor van Jetstream (en zeg dus maar dag tegen Bootstrap).

Wat een bagger ontwikkelaars zeg...

Ondertussen is versie 3.0 van laravel/ui uit met support voor Laravel 8: https://github.com/laravel/ui/releases/tag/v3.0.0

[Postman]

Barryvdh schreef op zaterdag 12 september 2020 @ 09:13:
[...]


Ondertussen is versie 3.0 van laravel/ui uit met support voor Laravel 8: https://github.com/laravel/ui/releases/tag/v3.0.0

Zag jouw bijdrage en de versie 3 inderdaad voorbij komen. Bedankt daarvoor.

Ik ga vandaag een begin maken met het omzetten van Jetstream (met Livewire) naar Bootstrap. Nog even kijken hoe ik dit het beste op GitHub kan plaatsen, het mooiste zou een auto build zijn maar dat gaat ver boven mijn kennis. Dus waarschijnlijk wordt het iets van een overschrijving van de blade bestanden.

Want hoewel UI nu weer werkt heb je grote kans dat het over 6 maanden opnieuw kapot gaat en als je ziet hoe bereid ze nu al waren om een nieuwe build te maken dan vrees ik dat het 2021 echt einde oefening is.

Uiteindelijk kost het mij nu wat meer tijd, maar hoop dat die tijd zich in de toekomst terug zal verdienen (plus ik heb geen echte noodzaak want het blog project was nog in ontwikkeling en min of meer hobby).

[Hiroj]

Postman schreef op zaterdag 12 september 2020 @ 10:27:
[...]

Zag jouw bijdrage en de versie 3 inderdaad voorbij komen. Bedankt daarvoor.

Ik ga vandaag een begin maken met het omzetten van Jetstream (met Livewire) naar Bootstrap. Nog even kijken hoe ik dit het beste op GitHub kan plaatsen, het mooiste zou een auto build zijn maar dat gaat ver boven mijn kennis. Dus waarschijnlijk wordt het iets van een overschrijving van de blade bestanden.

Want hoewel UI nu weer werkt heb je grote kans dat het over 6 maanden opnieuw kapot gaat en als je ziet hoe bereid ze nu al waren om een nieuwe build te maken dan vrees ik dat het 2021 echt einde oefening is.

Uiteindelijk kost het mij nu wat meer tijd, maar hoop dat die tijd zich in de toekomst terug zal verdienen (plus ik heb geen echte noodzaak want het blog project was nog in ontwikkeling en min of meer hobby).

Waarom denk jij dat Laravel in 2021 einde oefening kan zijn door de recente ontwikkelingen, waardoor (beginnende) programmeurs zich ook makkelijker op het framework kunnen richten?

Als een meer ervaren programmeur (lees meer dan 10 jaar ervaring) heb ik daar weinig moeite mee. Een framework zoals Laravel zorgt er tenminste voor dat de code overdraagbaar kan zijn naar andere ontwikkelaars toe.

[Barryvdh]

Hiroj schreef op maandag 14 september 2020 @ 11:39:
[...]


Waarom denk jij dat Laravel in 2021 einde oefening kan zijn door de recente ontwikkelingen, waardoor (beginnende) programmeurs zich ook makkelijker op het framework kunnen richten?

Als een meer ervaren programmeur (lees meer dan 10 jaar ervaring) heb ik daar weinig moeite mee. Een framework zoals Laravel zorgt er tenminste voor dat de code overdraagbaar kan zijn naar andere ontwikkelaars toe.

Ik denk dat hij bedoelt dat laravel/ui einde oefening is. Wat opzich niet heel raar zou zijn, aangezien Taylor en co aangegeven hebben dat ze laravel/ui niet meer zien als 'de goede oplossing', maar jetstream prefereren. Zie bijv. de reactie van Taylor hier hier: https://www.reddit.com/r/...ctions_to_jetstream_here/

Dat gezegd hebbende, ze zijn wel bijgedraaid met support voor Laravel 8 en het is even de vraag hoe Jetstream uitpakt in de praktijk. Wat mij betreft hebben ze gelijk over laravel/ui en React/Vue scaffolding, maar is de 'plain php' scaffolding soms nog wel handig.

[Hiroj]

Barryvdh schreef op maandag 14 september 2020 @ 12:54:
[...]


Ik denk dat hij bedoelt dat laravel/ui einde oefening is. Wat opzich niet heel raar zou zijn, aangezien Taylor en co aangegeven hebben dat ze laravel/ui niet meer zien als 'de goede oplossing', maar jetstream prefereren. Zie bijv. de reactie van Taylor hier hier: https://www.reddit.com/r/...ctions_to_jetstream_here/

Dat gezegd hebbende, ze zijn wel bijgedraaid met support voor Laravel 8 en het is even de vraag hoe Jetstream uitpakt in de praktijk. Wat mij betreft hebben ze gelijk over laravel/ui en React/Vue scaffolding, maar is de 'plain php' scaffolding soms nog wel handig.

Als dat zo is, dan kan hij best wel eens gelijk hebben ja. Maar goed, laravel/ui gebruik ik eigenlijk nauwelijks. Zie liever een pakket komen Laravel/auth zoiets, waarmee je enkel de scaffolding krijgt voor user management.

Alles na die stap in 95% van alle gevallen bij mijn klanten zijn maatwerk.

[Barryvdh]

Hiroj schreef op maandag 14 september 2020 @ 13:28:
[...]


Als dat zo is, dan kan hij best wel eens gelijk hebben ja. Maar goed, laravel/ui gebruik ik eigenlijk nauwelijks. Zie liever een pakket komen Laravel/auth zoiets, waarmee je enkel de scaffolding krijgt voor user management.

Alles na die stap in 95% van alle gevallen bij mijn klanten zijn maatwerk.

Ja opzich was laravel/ui met de standaard bootstrap scaffolding ook niet veel meer als login+register in de bootstrap divjes.

[Postman]

Hiroj schreef op maandag 14 september 2020 @ 11:39:
Waarom denk jij dat Laravel in 2021 einde oefening kan zijn door de recente ontwikkelingen, waardoor (beginnende) programmeurs zich ook makkelijker op het framework kunnen richten?

Inderdaad zoals @Barryvdh al aangeeft bedoel ik dat in 2021 de support voor Laravel/UI zal stoppen.

Dat gezegd hebbende, ze zijn wel bijgedraaid met support voor Laravel 8 en het is even de vraag hoe Jetstream uitpakt in de praktijk. Wat mij betreft hebben ze gelijk over laravel/ui en React/Vue scaffolding, maar is de 'plain php' scaffolding soms nog wel handig.

Ja opzich was laravel/ui met de standaard bootstrap scaffolding ook niet veel meer als login+register in de bootstrap divjes.

Precies dat mis ik nu in de Jetstream optie. Al zou het een optie zijn om niets aan CSS/JS te kiezen zou het al helpen. Aangezien je nu compleet overstelpt wordt met Tailwind is het niet makkelijk hier weer Bootstrap van te maken.
Nu kon je argumenteren dat je vroeger gedwongen werd om met Bootstrap of Vue te werken, nu wordt opeens Tailwind door je strot geduwd.

Het grote nadeel van Tailwind vind ik dat de HTML code totaal onleesbaar is in development. Er zullen vast voordelen zijn, ik zie ze nog niet.

[Hiroj]

Postman schreef op maandag 14 september 2020 @ 16:54:
[...]

Inderdaad zoals @Barryvdh al aangeeft bedoel ik dat in 2021 de support voor Laravel/UI zal stoppen.


[...]


[...]

Precies dat mis ik nu in de Jetstream optie. Al zou het een optie zijn om niets aan CSS/JS te kiezen zou het al helpen. Aangezien je nu compleet overstelpt wordt met Tailwind is het niet makkelijk hier weer Bootstrap van te maken.
Nu kon je argumenteren dat je vroeger gedwongen werd om met Bootstrap of Vue te werken, nu wordt opeens Tailwind door je strot geduwd.

Het grote nadeel van Tailwind vind ik dat de HTML code totaal onleesbaar is in development. Er zullen vast voordelen zijn, ik zie ze nog niet.

Zou het niet een idee zijn dat wij samen zo'n dergelijk pakket maken? Ik heb opgemerkt dat veel mensen hierover mopperen en behoefte hebben aan hetgeen wat wij hier ook bespreken.

[Barryvdh]

Hiroj schreef op dinsdag 15 september 2020 @ 10:09:
[...]


Zou het niet een idee zijn dat wij samen zo'n dergelijk pakket maken? Ik heb opgemerkt dat veel mensen hierover mopperen en behoefte hebben aan hetgeen wat wij hier ook bespreken.

Ja behalve dat laravel/ui dat is en ook nog gewoon werkt, dus voor mij niet perse de noodzaak om NU een alternatief te gaan ontwikkelen

[Chris7]

Postman schreef op maandag 14 september 2020 @ 16:54:
Het grote nadeel van Tailwind vind ik dat de HTML code totaal onleesbaar is in development. Er zullen vast voordelen zijn, ik zie ze nog niet.

Ik heb er onlangs hier in het topic wat over geschreven: Chris7 in "[PHP] Het grote Laravel topic"

Ik was eerst ook scepticus maar na Tailwind gebruikt te hebben is mijn mening erover snel gedraaid. Het nadeel van minder leesbare HTML weegt in mijn ogen niet op tegen de voordelen.

[HollowGamer]

Wat is best practice als je wilt upgraden naar Laravel 8 als je nogal wat extra packages hebt geïnstalleerd? Is er een checker die je kan gebruiken welke packages nog niet zijn bijgewerkt?

Spatie is altijd heel erg snel, maar ik twijfel een beetje over de andere. Opzicht niet erg, het hoeft niet direct en sta altijd open om een PR te maken wanneer nodig.

[Chris7]

HollowGamer schreef op woensdag 16 september 2020 @ 08:40:
Wat is best practice als je wilt upgraden naar Laravel 8 als je nogal wat extra packages hebt geïnstalleerd? Is er een checker die je kan gebruiken welke packages nog niet zijn bijgewerkt?

Spatie is altijd heel erg snel, maar ik twijfel een beetje over de andere. Opzicht niet erg, het hoeft niet direct en sta altijd open om een PR te maken wanneer nodig.

Laravel Shift heeft een upgrade checker voor packages, die werkt best goed. Net mijn require en require-dev blokken erin gegooid en hij herkent niet alle packages, maar dan blijven er een stuk minder over om handmatig te checken.

Je kan Laravel Shift ook gebruiken om automatisch je applicatie te upgraden. Bij de upgrade naar Laravel 7 een keer gebruikt en ik was er erg tevreden over, het bespaart toch best wat tijd voor erg weinig geld.

[Poinsy]

Hiroj schreef op maandag 14 september 2020 @ 13:28:
[...]


Als dat zo is, dan kan hij best wel eens gelijk hebben ja. Maar goed, laravel/ui gebruik ik eigenlijk nauwelijks. Zie liever een pakket komen Laravel/auth zoiets, waarmee je enkel de scaffolding krijgt voor user management.

Alles na die stap in 95% van alle gevallen bij mijn klanten zijn maatwerk.

De documentatie van Fortify is inmiddels geschreven lees ik net. Taylor geeft aan op Reddit dat Fortify dus eigenlijk de authentication logic is zonder de fronted templates e.d.

[Barryvdh]

Poinsy schreef op woensdag 16 september 2020 @ 11:24:
[...]


De documentatie van Fortify is inmiddels geschreven lees ik net. Taylor geeft aan op Reddit dat Fortify dus eigenlijk de authentication logic is zonder de fronted templates e.d.

Ja idd, dus eigenlijk zou je alleen laravel/ui hoeven te forken en aan te passen dat het Fortify gebruikt.

[Saven]

Ha, even iedereen weer wakker schoppen

Misschien is er een veel nettere oplossing voor wat ik had bedacht (en dus niet werkt). Ik wil eigenlijk eenzelfde route url hebben, waarbij op basis van de route parameters, een andere controller method wordt aangeroepen.

Voorbeeld:

PHP:

Route::get('/connect/{platform}/{module}', 'ConnectorController@platformA')
   ->where('platform', 'platformA')
   ->name('installer.a');

Route::get('/connect/{platform}/{module}', 'ConnectorController@platformB')
   ->where('platform', 'platformB')
   ->name('installer.b');

De reden hiervoor is dat ik $platform als 'route model' bind in de Controller, en dus dynamisch kan zijn. Maar de methods platformA en platformB verschillen in dit geval zodanig van logica dat het imo logischer is om twee verschillende methods te gebruiken.

Maar Laravel ziet de eerste route niet Alleen de tweede route is aan te roepen.

Een workaround zou zijn door met URL segments te werken, maar dat vind ik dan weer minder sjiek. Moet ik zelf het model inladen enzo.

Misschien heeft iemand anders een best practice c.q. betere oplossing dan wat ik heb bedacht met de url segments?

[Cartman!]

Saven schreef op dinsdag 29 september 2020 @ 15:34:
Misschien heeft iemand anders een best practice c.q. betere oplossing dan wat ik heb bedacht met de url segments?

Je wil nu logica oplossen in je routes; dat vind ik niet logisch. Ik zou die platform uitlezen in je controller en dan in je controller een service aanroepen die op basis van waarde A of B iets gaat doen.

Overigens, als je t perse met routes wilt doen, waarom maak je er dan een variabele van, dan kun je net zo goed het platform hardcoden in je route.

[ Voor 14% gewijzigd door Cartman! op 29-09-2020 16:22 ]

[Postman]

Eindelijk een begin gemaakt aan mijn conversie van Jetstream Livewire naar Bootstrap 4. Ik heb er voor gekozen om gebruik te blijven maken van de Livewire calls en componenten, en dus wel alle CSS om te zetten naar Bootstrap (waar mogelijk).

Tot op heden alleen de login & registratie pagina gedaan. Zal wel even duren voor ik alle componenten heb omgezet, ook omdat het niet altijd direct via Bootstrap op te lossen is (er blijft custom CSS nodig).

Of het überhaupt een voordeel heeft wat ik nu aan het doen ben begin ik ook een beetje te betwijfelen, maar het zorgt er in ieder geval voor dat ik geen dependency meer heb op Tailwind (hoewel ik daar ook geen referentie naar zie/zag, wel iets van AlpineJS?).

De GitHub is publiek onder https://github.com/fullslackdev/jetstream_bootstrap. Het zijn nog 3 losse mappen daarin, uiteindelijk ga ik een refactor doen en naar alleen 1 map (de bootstrap variant). Maar voor nu is het om de 3 versies te kunnen vergelijken.

[-DarkShadow-]

Laravel dependency injection zou toch op ieder object moeten werken?

Ik gebruik Spatie's Queueable Actions en die probeer ik te gebruiken met DI.

Mijn actie is als volgt, dus DI via de constructor:

PHP:

class SyncSomethingAction
{
    use QueueableAction;
    protected $service;

    public function __construct(Service $service) {
        $this->service = $service;
    }

    public function execute(int $arg)
    {
        ...

Die roep ik als volgt aan vanuit een andere actie:

PHP:

(new SyncSometingAction)->onQueue()->execute(1);

Hierbij krijg ik terug van PHP dat het argument voor de constructor van SyncSomethingAction ontbreekt. Dus DI werkt niet. Ik heb al enkele bekende services gebruikt die zeker zouden moeten werken, maar ook daarbij krijg ik dezelfde Exception. Wat mis ik?

[ Voor 198% gewijzigd door -DarkShadow- op 05-10-2020 14:28 ]

[PatrickH89]

Als je handmatig de class instantieert kan de container dat natuurlijk niet voor je doen

De Service kun je bij een controller (of andere service) laten injecten om die vervolgens zelf door te geven aan je SyncSomethingAction.

[ Voor 43% gewijzigd door PatrickH89 op 05-10-2020 21:12 ]

[Barryvdh]

Ja of je kan hem via de App container direct laten resolven:

code:

app(SyncSometingAction::class)->onQueue()->execute(1)

[ Voor 9% gewijzigd door Barryvdh op 05-10-2020 22:25 ]

[PatrickH89]

Barryvdh schreef op maandag 5 oktober 2020 @ 22:24:
Ja of je kan hem via de App container direct laten resolven:

code:

app(SyncSometingAction::class)->onQueue()->execute(1)

Dit kan absoluut, maar meestal als je een call als deze 'nodig' hebt klopt er iets niet met je structuur. Laravel heeft een krachtige IoC container, het zou jammer zijn om die aan te roepen dmv een Service Locator.

[-DarkShadow-]

PatrickH89 schreef op dinsdag 6 oktober 2020 @ 10:00:
[...]


Dit kan absoluut, maar meestal als je een call als deze 'nodig' hebt klopt er iets niet met je structuur. Laravel heeft een krachtige IoC container, het zou jammer zijn om die aan te roepen dmv een Service Locator.

Ik gebruik momenteel de "Beyond CRUD" architectuur van Spatie, maar dit is dan wel een flinke hiaat in de architectuur. Indien onQueue wordt gebruikt, wordt de service geresolved door de queue. Maar indien je de actie direct gebruikt, loop je tegen dit probleem aan.

[basvaningen]

Als "Vue" beginner blijf ik een beetje worstelen met authenticatie en zie dat de meeste tutorials onvolledig zijn of gewoonweg niet werken.
Ik heb nu deze tutorial gevolgd en dit werkt op 1 ding na. Misschien dat jullie mij kunnen helpen.

https://blog.codecourse.c...-authentication-with-vue/

Het probleem is dat als je ingelogd bent en je laat de pagina open laat staan je cookie verloopt na een X periode. Echter blijf ik wel ingelogd in de Vue app, maar zie ik wel in de console dat als er data opgehaald moet worden je "not authorized" bent.
Wat is in deze situatie volgens jullie de "best practice" om dit te checken. In de VueX store wordt al wel de user state opgeslagen, maar ik ben nog niet zover kwa kennis om te zien of dat ook goed en realtime (reactive) gebeurd in deze tutorial.

Alvast bedankt voor jullie hulp!!

[patricks8]

basvaningen schreef op vrijdag 23 oktober 2020 @ 09:01:
Als "Vue" beginner blijf ik een beetje worstelen met authenticatie en zie dat de meeste tutorials onvolledig zijn of gewoonweg niet werken.
Ik heb nu deze tutorial gevolgd en dit werkt op 1 ding na. Misschien dat jullie mij kunnen helpen.

https://blog.codecourse.c...-authentication-with-vue/

Het probleem is dat als je ingelogd bent en je laat de pagina open laat staan je cookie verloopt na een X periode. Echter blijf ik wel ingelogd in de Vue app, maar zie ik wel in de console dat als er data opgehaald moet worden je "not authorized" bent.
Wat is in deze situatie volgens jullie de "best practice" om dit te checken. In de VueX store wordt al wel de user state opgeslagen, maar ik ben nog niet zover kwa kennis om te zien of dat ook goed en realtime (reactive) gebeurd in deze tutorial.

Alvast bedankt voor jullie hulp!!

Waar je heel goed naar moet kijken zijn de Session domains en stateful domains die je kan zetten in je .env van je Laravel backend. Dat probleem heb ik namelijk gehad dat deze niet goed geconfigureerd waren. Daardoor lukt inloggen wel, maar elke volgende request een 403.

[basvaningen]

Ik zie net dat ik een apart topic moet aanmaken voor mijn vraag. Heb dit zojuist gedaan. De mod mag dus het bericht van mij verwijderen.

[VUE + Laravel] Authenticatie

[ Voor 17% gewijzigd door basvaningen op 23-10-2020 12:08 ]

[Barryvdh]

Hiroj schreef op maandag 31 augustus 2020 @ 13:00:
[...]

Ik heb wel een leuk project waarmee ik eens goed TailwindCSS en Livewire kan uitproberen. Ben benieuwd wat ik er uiteindelijk van ga vinden.

En hoe bevalt Livewire? Ik heb ook wat ge-experimenteerd met Livewire en tot nu toe bevalt het wel. Voor een eigen project en en nu ook voor een onderdeel op een klant project. Ook een stukje over geschreven: https://barryvdh.nl/larav...ar-with-laravel-livewire/

Blijft even wennen maar soms is het wel erg makkelijk om gewoon een PHP functie aan te roepen vanuit Javascript, of een event af te vuren vanuit PHP en op te vangen met Javascript

[llevering]

Barryvdh schreef op dinsdag 27 oktober 2020 @ 17:02:
[...]


En hoe bevalt Livewire? Ik heb ook wat ge-experimenteerd met Livewire en tot nu toe bevalt het wel. Voor een eigen project en en nu ook voor een onderdeel op een klant project. Ook een stukje over geschreven: https://barryvdh.nl/larav...ar-with-laravel-livewire/

Blijft even wennen maar soms is het wel erg makkelijk om gewoon een PHP functie aan te roepen vanuit Javascript, of een event af te vuren vanuit PHP en op te vangen met Javascript

Ik zag je blog voorbij komen, erg leuk om te zien, wat net een paar uur daarvoor had ik gedacht: 'Hoe zou Livewire wrappen om Fullcalendar'. Nog geen concreet use-case voor, maar ik gebruik het in veel projecten, dus dat komt vanzelf voorbij.

[Hiroj]

Barryvdh schreef op dinsdag 27 oktober 2020 @ 17:02:
[...]


En hoe bevalt Livewire? Ik heb ook wat ge-experimenteerd met Livewire en tot nu toe bevalt het wel. Voor een eigen project en en nu ook voor een onderdeel op een klant project. Ook een stukje over geschreven: https://barryvdh.nl/larav...ar-with-laravel-livewire/

Blijft even wennen maar soms is het wel erg makkelijk om gewoon een PHP functie aan te roepen vanuit Javascript, of een event af te vuren vanuit PHP en op te vangen met Javascript

Ik heb het uitgeprobeerd bij een nieuw project. Tot nu toe ben ik wel erg te spreken over de mogelijkheden ermee, maar zodra ik meerdere css klasses moet togglen ben ik wel eventjes zoet...

TailwindCSS bevalt mij daarentegen echt verrassend goed. Ik heb nu wel onwijs veel componenten in mijn code, maar als je weet bij welke je moet zijn dan gaat het hartstikke goed komen

[Thandruil]

Wij zijn sinds een week of twee ook bezig geweest met het in kaart brengen of Livewire een goede toevoeging in ons project kan zijn. Nu is het een Laravel+GraphQL+React app, maar waar we vooral tegenaan liepen was de hoeveelheid boilerplate code (mutations en queries schrijven) en het de tijd die het kost voor het bedenken van een logische API.

Nu met Livewire hebben we in korte tijd een groot deel van de app kunnen schrijven. Zelfs het herschrijven van een aantal dynamische UI components in Alpine viel eigenlijk alleen maar mee. Enige wat ik tot nu toe mis is dat de Livewire app niet echt een "pagina state" bijhoudt, zelfs met Turbolinks. Zo is het lastig om de state van bijvoorbeeld een inklapbaar menu tussen page loads bij te houden.

[Hiroj]

Thandruil schreef op zondag 1 november 2020 @ 23:14:
Wij zijn sinds een week of twee ook bezig geweest met het in kaart brengen of Livewire een goede toevoeging in ons project kan zijn. Nu is het een Laravel+GraphQL+React app, maar waar we vooral tegenaan liepen was de hoeveelheid boilerplate code (mutations en queries schrijven) en het de tijd die het kost voor het bedenken van een logische API.

Nu met Livewire hebben we in korte tijd een groot deel van de app kunnen schrijven. Zelfs het herschrijven van een aantal dynamische UI components in Alpine viel eigenlijk alleen maar mee. Enige wat ik tot nu toe mis is dat de Livewire app niet echt een "pagina state" bijhoudt, zelfs met Turbolinks. Zo is het lastig om de state van bijvoorbeeld een inklapbaar menu tussen page loads bij te houden.

Zou je dat niet met een sessie kunnen oplossen? Beetje out-of-the-box denkend hoor. Als je een menu openklapt, kun je prima in de PHP code een methode aanspreken die zowel het uitklappen als het plaatsen van een sessie waarde kan verzorgen.

Bij iedere page load check je vervolgens of die sessie waarde dan bestaat.

[Nonstop365]

Thandruil schreef op zondag 1 november 2020 @ 23:14:
Wij zijn sinds een week of twee ook bezig geweest met het in kaart brengen of Livewire een goede toevoeging in ons project kan zijn. Nu is het een Laravel+GraphQL+React app, maar waar we vooral tegenaan liepen was de hoeveelheid boilerplate code (mutations en queries schrijven) en het de tijd die het kost voor het bedenken van een logische API.

Nu met Livewire hebben we in korte tijd een groot deel van de app kunnen schrijven. Zelfs het herschrijven van een aantal dynamische UI components in Alpine viel eigenlijk alleen maar mee. Enige wat ik tot nu toe mis is dat de Livewire app niet echt een "pagina state" bijhoudt, zelfs met Turbolinks. Zo is het lastig om de state van bijvoorbeeld een inklapbaar menu tussen page loads bij te houden.

Is dit niet de oplossing?
https://laravel-livewire.com/docs/2.x/query-string

[Barryvdh]

Ik denk dat hij bedoeld buiten het component om, dus als je wisselt van het ene naar andere component. Met turbolinks zou dat goed moeten gaan zolang je menu buiten je content container zit toch?

[Thandruil]

Barryvdh schreef op donderdag 5 november 2020 @ 09:25:
Ik denk dat hij bedoeld buiten het component om, dus als je wisselt van het ene naar andere component. Met turbolinks zou dat goed moeten gaan zolang je menu buiten je content container zit toch?

Ja, precies. Livewire components zelf werken sowieso, de DOM wordt enkel van de component vervangen. Maar Turbolinks vervangt wel de gehele <body> inhoud, dus bij het navigeren van routes.