Subscribe
Popular posts from PHPDeveloper.org for the past week:
Here's what was popular in the PHP community one year ago today:
On his Medium.com blog Zeeshan Ahmad has posted a tutorial showing you how to set up JWT authentication in a Lumen application. Lumen is a micro-framework based on the larger Laravel framework's components.
Recently I have been tinkering with Vue.js to get a taste of it and I decided to create a quick project to get my hands dirty. I decided to create a blog with authentication etc. My main focus was on the frontend so I decided to quickly bootstrap an application in Lumen because of its simplicity and almost zero-configuration development. For the authentication, I decided to go with JWT and this post is going to be a quick write-up on how I integrated that and how anyone can integrate JWT authentication in their APIs.
He then walks you through the process of creating the application, creating the required configuration files/settings and the creation of the model and migration for the users table in the database. After populating the table with some fake seed data, he uses Composer to pull in the firebase/php-jwt library. From there he includes the code for the User controller and the JWT middleware that will handle the decoding of the token and locating the matching user. In his example it doesn't show the authentication process for the creation of the token, just the validation once it's set.
The Laravel News site has a quick tutorial posted showing you how you can use Eloquent functionality to help prepare your URLs and make them easier to maintain across the application. The key is in the use of "presenters".
It’s not uncommon to have tens, if not hundreds of views in a Laravel application. Something that soon gets out of hand is the various references to routes. [...] If for whatever reason we have to make a change to either the route alias or default query string values you’ll soon find yourself doing mass string replacements across your entire application which brings the risk of breakage within many files.What can we do to possibly better handle this? There are a couple of different approaches.
They provide two approaches, one being slightly more complex (but flexible) than the other. The first makes use of only Eloquent to define a getUrlAttributes method in the model. The second method abstracts this functionality out to a "URL Presenter", a class that defines methods for each of the CRUD actions and returns the correct route for each. The getUrlAttribute then returns an instance of this instead, making it easy to reference the method and route required in the Blade template.
The Stitcher.io blog has a new post from author Brentd sharing some thoughts about what PHP could be if "that one feature" were added. For him it would be a true strong typing system that didn't require workarounds to make happen.
Have you ever wondered how your life as a PHP developer would be different if that one feature you want was added? I've made the thought experiment quite a few times already, and came to surprising conclusions.Let's take, for example, the debate about strong types in PHP. A lot of people, including myself, would like a better type system. Strong types in PHP would definitely have an impact on my daily work. Not just strong types, I also want generics, better variance and variable types. Improvements to PHP's type system in general would have quite the impact on my programming life.
So what's stopping us from reaching a solution?
He covers a few different topics in his discussion of the feature including issues around common vocabulary and the use of the feature (in this case type enforcement). He finishes the post talking about the impact a feature like this could have on PHP and some of the benefits that could come with a strongly typed version of the language.
In a new post to his site Matthias Noback takes a look at legacy applications and two things that most of them seem to have in common: classes that are too large and too generic methods. In this post he discusses these two topics and some of the tactics you can use to help refactor and resolve them.
I find it very curious that legacy (PHP) code often has the following characteristics:
- Classes with the name of a central domain concept have grown too large.
- Methods in these classes have become very generic.
He starts by tackling the "classes too large" problem, suggesting that it's usually just a matter of developers slowly adding to existing functionality rather than introducing large chunks of code all at once. Moving on to the "generic methods" issue, he lays out a common scenario showing how a method evolves over time to repurpose it for other uses thank its original intent. He recommends "taking a step back" and picking apart the code to make the functionality more specific in the places it's used.
Recent posts from the PHP Quickfix site:
Latest PECL Releases:
In a new post to his site Woody Gilk showing how to use custom Composer hooks to run PHP style checks (using PHP_CodeSniffer) on your codebase and setting up the same configuration for all developers.
One of thing that has always bothered me about phpcs is that the lack of a local configuration file.The official way to set the default standard for a project is [to set the standard on the command line]. This will write to a configuration file inside the vendor/ directory, which means that the configuration cannot be committed to version control. When a new team member is added they must also run this command or different style checks will be used.
Luckily, this can be solved with composer command events, namely the post-install-cmd and post-update-cmd events, which can be pointed to a PHP class that processes the event.
He includes the configuration changes showing how to set up the command in the Composer configuration to run post-install/update and the code required to set the phpcs standard to use. While this method works, he has also updated the post with an example of a single (XML) configuration file that accomplishes the same thing.
On his Medium.com site Benoit Schneider (CTO of Outsourcify) has a post sharing some of the reasons they made the choice to use Symfony for their web development needs.
At Outsourcify we work on projects of varying sizes, from small sites with a few pages to complex business applications. Depending on the case, we recommend different technical solutions (we do a lot of Javascript SPA and Wordpress also), but for the most complex cases, when we have to chose a technology to build large web applications that require several weeks or months of work for several web developers, Symfony is our framework of choice.
He starts with a bit of background on his own experiences with Symfony and why he chose it for his own needs early on. He then shares his thoughts around "why Symfony?" when there are many other major frameworks to choose from. He wraps up the post with a summary of some technical reasons to use the framework including the innovation it brings to the table and the robust ecosystem around it (and related products/tools).
@phpdeveloper.org