Every two weeks I send out a newsletter containing lots of interesting stuff for the modern PHP developer. You can expect quick tips, links to interesting tutorials, opinions and packages. Want to learn the cool stuff? Then sign up now!

A conversation on laravel-html

Hi, how are you?
I’m fine thanks! How are you?

I saw you released another package last week.
Yup yup, you mean laravel-html, right? It was actually coded up by my colleague Sebastian, who did an awesome job.

But why put out yet another html generator? Html generation is a solved problem, right?
Yes, it is but…

I’m mean we already have laravelCollective/html
Yes, but…

Why not just type html, … come on, do we really need a package for this? It’s easy to just type html.
Let me say first that if you’re happy with your current solution, just stick with it. There’s no right or wrong here. Because everybody already has their own favourite solution, html generation is a pretty divisive subject. I believe that’s why html generation was kicked out of the Laravel core.

Stop rambling, just tell why you’ve created this.
Well, like probably most fellow artisans we have been using the laravel collective package for quite some time and we were quite happy with it. Since html generation got kicked out of the Laravel core and has been put in the laravel collective package it has not evolved much. Take for instance this piece of code:

Form::email('element-name', null, ['class' => 'my-class']);

Seems like this is quite simple solution, but a few things bother me. That null parameter for instance when there is no value. And the fact that you need pass an array as the third parameter. In our package all html can be built up with a fluent interface. So you can do this:


Yeah ok, that’s certainly nice, but do you plan to code all of your html like this?
No, certainly not. For simple things I prefer just writing the html. But when it comes to generating forms, I prefer using our package. Because when typing forms manually there’s so much things to you need to take care of: the method field, the csrf token field etc… it’s very error prone.

Here’s how you can create a form with laravel-html:

html()->form('PUT', '/post')->open();
html()->email('email')->placeholder('Your e-mail address');
html()->submit('Process this');

That’ll output:

<form method="POST" action="/post">
    <input type="hidden" name="_method" id="_method" value="PUT">
    <input type="hidden" name="_token" id="_token" value="csrf_token_will_be_here">
    <input type="email" name="email" id="email" placeholder="Your e-mail address">
    <input type="submit" value="Process this">"

As you can see those hidden _method and _token fields were added automatically.

You can also use models or anything that implements ArrayAccess really to prefil the values of the form.



So if name is set on user the form element will receive it’s value.

<input type="text" name="name" id="name" value="John">

This all sounds interesting, please continue.
Well, if you want to know more, you really should really check out the documentation. It contains all you need to know. If you have a question about the package feel free to open up an issue at GitHub.

Is there anything more that we should know about the package?
It’s PHP 7.1 only.

Wut? Can you create a PHP 7.0 or PHP 5.6 version?
Boring. Next question.

But why did you make it PHP 7.1 only? My projects do not use that version yet.
We mainly create packages to use them in our own projects. All our new client projects use PHP 7.1, so it makes no sense for us to create packages for an older version of PHP.

But PHP 7.0 is still an active version…
I really don’t care. You’re of course free to fork the package and maintain your own copy that’s compatible with an older PHP version. Yay for open source.

Ok, I’ll go check it out!
Please do, like already mentioned the docs are here. And be sure to take a look at the other packages we’ve created previously.

Freek Van der Herten is a partner and developer at Spatie, an Antwerp based company that specializes in creating web apps with Laravel. After hours he writes about modern PHP and Laravel on this blog. When not coding he’s probably rehearsing with his kraut rock band. He loves waffles and butterflies.
  • Cagatay Ulubay

    “Backward compa-”
    “Boring! Next question!”
    “But what if-”

    In terms of Form management, I like how Symfony is handling it.

    The most operations are more or less hidden, csrf token automatically added etc.
    Validation done per Entity Annotations and final code lines are pretty low.

    For everything view related, I recommend only using real HTML combined with PHP if you need dynamic output (like username, date or entity property output etc) and Javascript if you need clientside dynamic.

  • Spatie’s boss. ๐Ÿ˜‰

  • hackel

    Great post!

    Does the package automatically associate a particular html()->model() with all fields in-between form()->open()/close() calls? Personally I would prefer something more explicit for multiple forms on a page, such as:

    $form1 = html()->form()->model($a)->open();

    $form2 = html()->form()->model($b)->open();

    Or perhaps with a unique identifier? html()->form(‘form1′)->email(’email’)