In a post to his site Tomas Votruba introduces something that can be helpful for those working with Symfony 4 and Flex to make the "zero-setup configuration" easier to work with: effective use of the Symfony Flex Loader.

Symfony 4 and Flex is heading in direction of zero-setup configuration - no bundles, no extensions, no configuration. You already know how to get rid of Configuration. Flex now loads services instead of Extension class.

But it has an extra price, a lot of new boilerplate code in Kernel. Today you'll learn how to keep your Kernel Flex-ready and clean at the same time.

He starts with an example kernel that loads an extra directory (defined by a "custom path"). He shows how to refactor these examples to "make them small again" making use of the Flex loader package that reduces the number of lines required to accomplish the same end result.

The TutsPlus.com site has continued their series looking at namespace-based autoloading in WordPress applications with part two. In this latest article they build on the simple plugin from part one and enhancing it with more functionality and autoloaded classes.

In the previous tutorial, we began talking about namespaces and autoloading with PHP in the context of WordPress development. And although we never actually introduced either of those two topics, we did define them and begin laying the foundation for how we'll introduce them in an upcoming tutorial.

Before we do that, though, there's some functionality that we need to complete to round out our plugin. The goal is to finish the plugin and its functionality so that we have a basic, object-oriented plugin that's documented and works well with one caveat; it doesn't use namespaces or autoloading.

This, in turn, will give us the chance to see what a plugin looks like before and after introducing these topics.

They start off with a quick review of the setup and previous development work done on the plugin making it easier to load in Javascript templates in a dynamic way. The plugin is then ready to start helping with the plugin use. They add in a basic CSS file to the site's "assets" folder and enqueue it. They start updating the plugin code, adding in an assets interface, a CSS loader and some styling for the box shown on the edit post interface.

In his latest post Joshua Thjissen looks at the creation of a custom configuration loader for a Symfony2 application. This kind of thing is mostly useful for parsing configurations that Symfony2 doesn't already know how to parse.

It happens more and more: large projects where your symfony2 site is just a small part in the big picture. Lots of additional components might even play a bigger part, especially when you are dealing with asynchronous components which are connected through message queues for instance. [...] Our first idea is obvious: symfony2 uses by default a parameters.yml file, which gets imported by your configuration (config.yml) [...] So nothing new here and this setup works perfectly, provided that your symfony2 project is the ONLY thing that needs to be configured. As soon as you add multiple other components (like gearman or activemq workers that need to connect to solr too), they need to share this configuration.

His solution involves falling back to the INI-file format that's known as useful for several different languages and tools. Because of how Symfony2 reads these files though (only looking for "parameters") he's had to create a "ConfFileLoader" instance of the "FileLoader" that uses the parse_ini_file method to parse the data and return it back to the main container as parameters. He also includes the code/config you'll need to implement this custom loader into your application.

In his latest post Joshua Thjissen looks at the creation of a custom configuration loader for a Symfony2 application. This kind of thing is mostly useful for parsing configurations that Symfony2 doesn't already know how to parse.

It happens more and more: large projects where your symfony2 site is just a small part in the big picture. Lots of additional components might even play a bigger part, especially when you are dealing with asynchronous components which are connected through message queues for instance. [...] Our first idea is obvious: symfony2 uses by default a parameters.yml file, which gets imported by your configuration (config.yml) [...] So nothing new here and this setup works perfectly, provided that your symfony2 project is the ONLY thing that needs to be configured. As soon as you add multiple other components (like gearman or activemq workers that need to connect to solr too), they need to share this configuration.

His solution involves falling back to the INI-file format that's known as useful for several different languages and tools. Because of how Symfony2 reads these files though (only looking for "parameters") he's had to create a "ConfFileLoader" instance of the "FileLoader" that uses the parse_ini_file method to parse the data and return it back to the main container as parameters. He also includes the code/config you'll need to implement this custom loader into your application.

Joshua Thijssen has a new post to his blog looking at a method for setting up ACL rules in fixtures for your Symfony2-based applications.

Doctrine’s DataFixtures are a great way to add test data to your application. It’s fairly easy to get this going: Create a fixureLoader that extends DoctrineCommonDataFixturesAbstractFixture, had a load() method and off you go. However, sometimes you want your data also to be protected by Symfony 2′s ACL layer. Since there isn’t a common way to do this, here is one way on how I implemented this.

His method uses the ContainerAware interface on the fixture loader instance to be able to get at the container for the fixture. This allows you to use the usual ACL handling methods of the framework to provide restrictions based on things like usernames and roles.

On the Refulz.com blog there's a new post looking at some of the new features in CakePHP 2.0 including its use of lazy loading, the CakeEmail library and the new class loader.

With CakePHP 2.0, they have dropped support for PHP 4 and have refactored the library code to make it strictly complaint with PHP 5.2+. Modeled on Ruby on Rails (RoR), CakePHP is a tough competition to Zend framework, Symfony and CodeIgniter.

Besides the topics mentioned above, he also goes into the details of the new CakeRequest and CakeResponse models (to access information about teh current request/response). Summaries of all of the new functionality are provided along with some sample code where needed to illustrate.

Jamie Rumbelow, a member of the CodeIgniter community, has a new post about a feature of the upcoming CodeIgniter 2.0 version of the framework - code packages.

This opens so many doors to developers, because, finally, we can bundle repeated functionality inside a package and distribute it as open-source or free code. Even if you don't want to expose your own packages, you can re-use them internally, which makes for a veritable mix of both writing application specific code, and abstracting elements of those applications out (such as an authentication engine, for instance) to become re-usable and unspecific.

He uses the post to give more specifics (that are currently missing from the manual) on what these packages are, how to use them via the framework's loader to both add and remove. Then, classes inside the package can be loaded just like any other CodeIgniter resource.

New on DevShed there's the latest part of a series of tutorials they've written up (fifth of eight) about building automatic loading functionality into your applications. This time they change up their class to make the their loading function accessible outside of a class object.

To avoid an eventual (and unnecessary) instantiation of the loader class, it would be helpful to declare the mentioned "load()" method static. Thus, bearing in mind this important concept, in this fifth part of the series I'm going to enhance the signature of the "Loader" class created previously by turning its loading method into a static one.

They change the definition of the function to be "public static" making it callable both through the "self" keyword and outside the class with the "::" operator.

DevShed has posted part three of their series looking at loader applications in PHP using the __autoload magic method.

While this file loading class in its current incarnation does a pretty good job, it lacks an important feature that could be added with relative ease. It cannot perform a recursive search through the web server's file system, and afterward include a specified file within a given application.

This article updates their class with a new feature to let the script looking for files recursively in a directory.

DevShed continues their "loaders in applications" series with this fourth part, a look at including files recursively.

This series uses a variety of code samples to teach you how to create modular programs. These programs are capable of recursively including files required by a given application, without having to explicitly call any "include()/include_once()" or "require()/require_once()" PHP function.

In their example they show how to use their loader class (built up from previous parts of the series) and modify it slightly to allow the script to set the file path, set the files to include and pull them in.