Matthias Noback has continued his series of tutorials covering various uses of the Repository design pattern. This is the second part of the series and picks up where part one left of, showing the handling of entities in the repository, performing the usual CRUD operations.

In part 1 of this short series (it's going to end with this article) we covered how you can test-drive the queries in a repository class. Returning query results is only part of the job of a repository though. The other part is to store objects (entities), retrieve them using something like a save() and a getById() method, and possibly delete them. Some people will implement these two jobs in one repository class, some like to use two or even many repositories for this. When you have a separate write and read model (CQRS), the read model repositories will have the querying functionality (e.g. find me all the active products), the write model repositories will have the store/retrieve/delete functionality.

In particular if you write your own mapping code (like I've been doing a lot recently), you need to write some extra tests to verify that the persistence-related activities of your repository function correctly.

He starts with the test cases for the functionality (following the test-drive design mentality) and talks about the expected behavior of the various entity and repository methods. He includes the code for these tests covering state changes, handling child entities, deleting entities, and working with ports/adapters.

On the Ibuildings site there's a tutorial posted talking about working with entities in Drupal 7 and how creating your own classes for them can make them easier to manage.

Developers love object-oriented code. But how can this be achieved with Drupal 7 entities? By default Drupal uses a single class for all entities of a given type. For example, all node objects are standard classes (stdClass) and all entity objects have the Entity type. I personally like to have an entity model that only exposes the functionality that is applicable for the logic of your domain.

[...] Wouldn’t it be nice to create your own classes for entities?

First off, he starts with a refresher on what entities are and how they relate to the database schema. He points out the difficulties in using them and testing their types. He then provides his suggested solution for "all" of your entity problems - the creation of classes for the different entity types. He gives an example using an Article type and how to create/use them in your Drupal code.

On the SitePoint PHP blog editor Bruno Skvorc continues his look at the Diffbot service and shows how to use their API to create entities representing objects from the API data.

A while back, we looked at Diffbot, the machine learning AI for processing web pages, as a means to extract SitePoint author portfolios. [...] Since then, the design of the pages we processed has changed, and thus the API no longer reliably works. In this tutorial, apart from rebuilding the API so that it works again, we’ll use the official Diffbot client to build custom entities that correspond to the data we seek (author portfolios).

He starts by setting up the environment for development (a Homestead Improved instance) and pulling in a few libraries to bootstrap the script. He shows the setup and configuration of the Diffbot client, creating a new API application via their UI and using the browser tools to help the service locate the information it needs. He then shows how to extend the client and define an "entity factory" to generate the objects requested. In this case he creates an AuthorFolio class to contain the author's number of posts.

In a new post to his site Benjamin Eberlei takes a look at the idea of "feature flags" (settings to turn on and off major features) and how they can be used with Doctrine entities to handle sync issues between new properties and the database schema.

The problem of feature flags with Doctrine is easily explained: If you add properties for a new feature that is disabled in the Doctrine metadata, then you need to upgrade the database before deployment, even when the feature is not being rolled out for some days/weeks. Doctrine requires the database to look exactly like the metadata specifies it.

His solution was to use the "loadClassMetadata" event in the entity to dynamically append these new properties based on simple "if" checks of feature flags in the configuration object. Obviously using this is a bit of a hack until the new properties are in place, but once they are then the only change is removing this code.

In this new post to his blog Matthew Weier O'Phinney looks at the steps he took to convert over the documentation for the Zend Framework 2 from the DocBook 4 formatting over to DocBook 5. Included in the post is some of the (PHP and bash) code he used to make the switch.

Within the Zend Framework 2 repository, I recently performed a conversion from DocBook 4 to 5. [...] Interestingly, for DocBook5 being available in beta since 2005 and an official standard since 2009, there is very little material on migrating from DocBook 4 to 5.

Right from the start he came across a few problems with the included conversion process that're a part of the "db4-update.xsl" definitions. He has a list of eight steps he had to perform on the current DocBook 4 formatted documentation to make the conversion work smoothly including:

• Identify files containing entity declarations, and skip them.
• Run the XML file through the db4-upgrade.xsl stylesheet and restore XML entities from the previously placed markers
• Fix programlisting elements (replaces entities with original text and wraps in CDATA).

He details these steps in a few different sections talking about handling the entities, creating some helper scripts and how to put the two code parts together in a single bash script that can be run on the entire documentation set. If you're just looking for the code, you can find it on his github account.