Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

[PHP] Het grote Laravel topic

Pagina: 1 ... 7 8 9 Laatste
Acties:

  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: april 2002
  • Niet online

CH4OS

It's a kind of magic

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

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

[ Steam ][ Diablo ][ CptChaos#2957 ]


  • Creepy
  • Registratie: juni 2001
  • Laatst online: 22:30

Creepy

Moderator Devschuur®

Tactical Espionage Splatterer

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

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have star problems" --Kevlin Henney


  • CH4OS
  • Registratie: april 2002
  • Niet online

CH4OS

It's a kind of magic

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

[ Steam ][ Diablo ][ CptChaos#2957 ]


  • Navi
  • Registratie: maart 2007
  • Laatst online: 23:09
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
  • Registratie: maart 2011
  • Niet online
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
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

Dit topic lijkt nogal dood, maar ik heb een vraagstuk :P

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:
1
Company::findOrFail( $request->company_id );


Iemand een suggestie of best practice?

  • r-v
  • Registratie: september 2008
  • Laatst online: 22-09 08:44
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:
1
2
3
4
5
6
7
8
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
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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:
1
2
3
4
5
6
7
8
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 :P

Edit ik ben ook iets tegengekomen als dit:
PHP:
1
app()->instance('Company', $company);

Die in de middleware geplaatst kan worden.

Alleen is
PHP:
1
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]


Acties:
  • +1Henk 'm!

  • r-v
  • Registratie: september 2008
  • Laatst online: 22-09 08:44
Je kan dit overigens ook oplossen met Route model binding

  • Saven
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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:
1
request('company')
moet ophalen omdat je daar logischerwijs geen dependency injection hebt.

  • TJVB
  • Registratie: januari 2008
  • Laatst online: 21-09 09:35
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:
1
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
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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 :P 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
    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:
1
2
3
4
5
6
7
8
9
10
11
    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:
1
$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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
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:
1
2
3
4
5
6
7
8
9
10
11
    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 :D :P

  • foxgamer2019
  • Registratie: februari 2009
  • Niet online
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
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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

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
  • Registratie: juli 2012
  • Niet online
Saven schreef op donderdag 23 juli 2020 @ 12:54:
Topic is helaas een beetje dood :o Toch probeer ik 't nog eens nieuw leven in te blazen met een vraag :P.

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
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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
  • Registratie: juli 2012
  • Niet online
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
  • Registratie: augustus 2004
  • Laatst online: 22:30
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:
1
`'someField' => 'required|string|MyCustomRule:someParameter'`


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

code:
1
`'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

Ryzen 1700@3.9Ghz 2x8GB 3200Mhz, Asrock X370 Taichi, Vega64


  • Voutloos
  • Registratie: januari 2002
  • Niet online
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]

Talkin.nl daily photoblog


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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:
1
`'someField' => 'required|string|MyCustomRule:someParameter'`


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

code:
1
`'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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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
  • Registratie: augustus 2004
  • Laatst online: 22:30
Barryvdh schreef op vrijdag 24 juli 2020 @ 09:56:
[...]


Je kan zoiets doen toch?

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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

Ryzen 1700@3.9Ghz 2x8GB 3200Mhz, Asrock X370 Taichi, Vega64


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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:
1
'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
  • Registratie: december 1999
  • Laatst online: 23:28

amphora

Online creatie

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.

kruijk.nl fotografie, Fuji X-T3, 10-24, 18-55/2.8-4, 35/1.4, 50-230
nickdekruijk.nl Webdesign/dev, MacBook Pro 15" Retina


Acties:
  • +1Henk 'm!

  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: januari 2007
  • Laatst online: 20:06

Matis

Rubber Rocket

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 :9B

If money talks then I'm a mime
If time is money then I'm out of time


  • Luc45
  • Registratie: april 2019
  • Laatst online: 22:51
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
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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:
1
2
$module = $company->modules()->where('name', 'Test Module')->first();
$settings = $module->settings;


$module geeft als query (ongeveer)
SQL:
1
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:
1
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:
1
2
$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
  • Registratie: september 2010
  • Laatst online: 22:36
Je zou in de settings relatie van je module een where statement kunnen toevoegen.

PSN: Skippy0810 | iRacing Profiel


  • Saven
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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 :P Heb nu het volgende en dat lijkt te werken :) Dus niet vanuit de Module model, maar vanuit de Company model.

PHP:
1
2
3
4
5
6
7
8
9
10
11
    // 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
  • Registratie: september 2010
  • Laatst online: 22:36
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 :P Heb nu het volgende en dat lijkt te werken :) Dus niet vanuit de Module model, maar vanuit de Company model.

PHP:
1
2
3
4
5
6
7
8
9
10
11
    // 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:
1
2
3
4
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]

PSN: Skippy0810 | iRacing Profiel


  • Saven
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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:
1
2
3
4
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
  • Registratie: augustus 2012
  • Laatst online: 07-09 18:34
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
  • Registratie: november 2009
  • Nu online
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
  • Registratie: augustus 2012
  • Laatst online: 07-09 18:34
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
  • Registratie: maart 2011
  • Niet online
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
  • Registratie: augustus 2012
  • Laatst online: 07-09 18:34
@Chris7 Bedankt voor de tip! Ziet er goed uit, ik ga er naar kijken!

  • Hiroj
  • Registratie: mei 2010
  • Laatst online: 22-09 13:03
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
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: mei 2010
  • Laatst online: 22-09 13:03
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
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: december 2005
  • Laatst online: 15:40
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
  • Registratie: mei 2010
  • Laatst online: 22-09 13:03
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
  • Registratie: maart 2011
  • Niet online
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
  • Registratie: mei 2010
  • Laatst online: 22-09 13:03
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
  • Registratie: maart 2011
  • Niet online
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
  • Registratie: november 2009
  • Laatst online: 16:52
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
  • Registratie: februari 2000
  • Laatst online: 23:38
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.

Systeemspecs


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: februari 2000
  • Laatst online: 23:38
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.

Systeemspecs


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: februari 2000
  • Laatst online: 23:38
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.

Systeemspecs


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: december 1999
  • Laatst online: 23:28

amphora

Online creatie

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)

kruijk.nl fotografie, Fuji X-T3, 10-24, 18-55/2.8-4, 35/1.4, 50-230
nickdekruijk.nl Webdesign/dev, MacBook Pro 15" Retina


  • Chris7
  • Registratie: maart 2011
  • Niet online
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
  • Registratie: november 2009
  • Nu online
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
  • Registratie: februari 2000
  • Laatst online: 23:38
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 8)7 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 :9) uit te pakken en alles goed te zetten. Scheelt allicht in de tijd want al die kleine meuk via FTP gaat traag :O

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.

Systeemspecs


  • scosec
  • Registratie: februari 2016
  • Laatst online: 21:58
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 8)7 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 :9) uit te pakken en alles goed te zetten. Scheelt allicht in de tijd want al die kleine meuk via FTP gaat traag :O

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
  • Registratie: februari 2000
  • Laatst online: 23:38
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...

Systeemspecs


  • PainkillA
  • Registratie: augustus 2004
  • Laatst online: 22:30
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.

Ryzen 1700@3.9Ghz 2x8GB 3200Mhz, Asrock X370 Taichi, Vega64


  • Postman
  • Registratie: februari 2000
  • Laatst online: 23:38
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).

Systeemspecs


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: februari 2000
  • Laatst online: 23:38
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.

Systeemspecs


  • Barryvdh
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: maart 2011
  • Niet online
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
  • Registratie: november 2009
  • Nu online
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
  • Registratie: december 2006
  • Laatst online: 22-09 13:30

Saven

Administrator

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
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: februari 2000
  • Laatst online: 23:38
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. d:)b

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).

Systeemspecs


  • Hiroj
  • Registratie: mei 2010
  • Laatst online: 22-09 13:03
Postman schreef op zaterdag 12 september 2020 @ 10:27:
[...]

Zag jouw bijdrage en de versie 3 inderdaad voorbij komen. Bedankt daarvoor. d:)b

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
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: mei 2010
  • Laatst online: 22-09 13:03
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
  • Registratie: juni 2003
  • Laatst online: 16:07
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
  • Registratie: februari 2000
  • Laatst online: 23:38
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.

Systeemspecs


  • Hiroj
  • Registratie: mei 2010
  • Laatst online: 22-09 13:03
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
  • Registratie: juni 2003
  • Laatst online: 16:07
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 :P

  • Chris7
  • Registratie: maart 2011
  • Niet online
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.

  • foxgamer2019
  • Registratie: februari 2009
  • Niet online
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
  • Registratie: maart 2011
  • Niet online
foxgamer2019 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
  • Registratie: september 2020
  • Laatst online: 21-09 21:21
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
  • Registratie: juni 2003
  • Laatst online: 16:07
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.
Pagina: 1 ... 7 8 9 Laatste


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True