In a new post to his site site Joseph Silber shows you how, when using Eloquent in a Laravel application, to decouple your application from your database by removing hard-coded class names on polymorphic relationships.

Polymorphic relations let you set up a relationship between many different model types, without the need for extra tables. This works by storing the "morphable type" (explained below) in the database, in addition to the morphable type's ID.

By default, the morphable type stored in the database is the model's full class name. While this works, it tightly couples your database to your PHP application. Let's look at how we can instruct Eloquent to use more generic values for these morphable types.

He starts in with a "short refresher" on polymorphic relationships and what Eloquent models look like for a simple customer-to-address relationship. He then talks some about the "morph" type and how Eloquent stores the name of the relating model directly in the record (like AppCustomer or AppWarehouse). He shows how to customize the morph type to map the types to values in a morphMap setting to remove the need for those hard-coded class names. He wraps up the post answering the question many ask: "why doesn't Eloquent do this automatically?"

The Pehapkari.cz blog has continued their series covering domain-driven design with the latest post in the series showing some alternative relational database mapping techniques.

Do you think that multilingual text must always be in a separate database table? Than this article is for you!

We will show that not all arrays have to be mapped as database tables. And we will also show the Doctrine implementation.

The article starts with a bit of background on what they're trying to accomplish: adding internationalization functionality to an e-commerce application. In order to make it simpler to work with the multi-language requirements they show the abstraction of its handling out into a LangValue value object that's used to store the product name value for each language. They then use this and some JSON encoded data to store the different language strings in the database directly with the product record rather than a different table. It then shows how to create the matching Doctrine entity for the LangValueType to work with the serialized column data and extract data from it's JSON blob.

Adam Wathan has a new post to his site talking about mapping with collections and customizing the keys when injecting new data into your Laravel collections.

People often ask me, “how do I specify keys when I’m mapping a collection?”

It actually ends up being a pretty interesting topic, so I decided to cover it in a short screencast, as well as in written format below.

He shows how to translate a simple set of data into a much more slimmed down version. He points out that the "map" function could be used but it doesn't allow for setting keys. Instead he talks briefly about how the problem could be solved in Javascript (returning an object instead of an array) and how to use the "reduce" method to filter and reset the data as it goes through the array. He finishes out the post talking about learning from other languages, the "toAssoc" macro on Laravel collections and mapping the data back to an array with a custom macro.

In a previous post Rob Allen showed you how to use Doctrine migrations as a standalone tool in your applications. In this new post he takes that a step further and shows you how to use the type mapping functionality (allowing for more customized column handling).

Shortly after starting to use Doctrine Migrations as a standalone tool in my project, I came across this error message [about an unknown database type "bit"]. This means that I have a column in my database of type bit which is used for booleans in SQL Server, but confuses the MySQL platform as it's not a default mapping. To support this, you need to modify the database connection's Platform object to know about the new mapping. However, with the setup that I'm using, I didn't have access to the connection object that's automatically created in the Migrations AbstractCommand object. After poking around in the code for a bit, I discovered that the solution is to create the connection object myself and then attach it as a new helper to the ConsoleApplication object.

He includes the code you'll need to add to your "migrations.php" file to set up the mapping relating his "bit" type example back to a "boolean" type. While this specific example is for the "bit" mapping, it shows how any mapping type can be added in. Finally he adds the connection (the one he set the type on) to enable it to be included in the helper set collection.

On the OpenShift blog Ryan Jarvinen has a new tutorial showing you how to use MongoDB and Silex to create a basic mapping service. It takes advantage of the MongoDB spatial data and query functionality to help locate and map items from the dataset.

Whether your goals are civic-minded or otherwise, PHP can help you craft solutions that are every bit as simple and elegant as what you might expect to see from modern Python, Ruby, or JavaScript frameworks. This particular example is intended to serve as a reusable template for folks who are interested in producing their own mapping applications - substituting in their own collection of map points or other spatial data.

He starts with a look at the datastore - the MongoDB - and the kind of data it will contain. He's shared the dataset (and complete example code too) over on Github and includes the command to import it. He then starts in on the PHP side of things, showing you how to get Silex installed and add in some basic routes and CSS. He then uses the Leaflet.js library to import the data and drop it into an Openstreetmap-based map. The full code and data can be found in this repository over on Github.

On PHPMaster.com a new tutorial has been posted showing how to combine Geocoder PHP with Leaflet.js to create interactive maps. The Leaflet.js library lets you easily create mobile-friendly maps with simplicity and usability in mind.

Interactive maps inside a web application have a lot of great uses. From visualizing data to highlighting points of interest, maps are expected to communicate ideas within the context of location easily. The hardest part, however, is converting that data into coordinates that the map can understand. Luckily, Geocoder PHP allows us to connect to different geo-coding providers. Combined with Leaflet.js, a simple Javascript library, creating maps is a breeze.

He starts by helping you get the Geocoder library installed via Composer and make a sample page (using Bootstrap and jQuery) with a container for the map. He helps you set up Geocoder with an adapter to connect to the service of your choice (like Google Maps, Bing Maps or Openstreatmap). With this configured and created, he inputs some sample data and coverts the addresses to latitude/longitude sets. He walks you through getting Leaflte.js added to the page and pulling in these results via individual generated Javascript variables. You can check out a demo of the end result to see how it all fits together too.

Gonzalo Ayuso has a new post today showing how you can use traits in PHP to simulate a kind of multiple inheritance.

Multiple inheritance isn’t allowed in PHP. [It's not] possible with PHP (in Java is not possible either), but today we can do something similar (is not the exactly the same) with Traits. Let me explain that: Instead of classes we can create Traits.

He includes a code example showing the creation of two traits, "Base1" and "Base2", that are implemented (via "use") and the calls to methods on each. He also points out the error condition and message that can come up when there's a conflict in the method names between two or more traits. This is relatively easy to solve with the mapping ability of the "use" statement (code example included for that too).

Lee Davis has a recent post to his blog showing how you can combine the Zend_Form component of the Zend Framework with Doctrine to help directly "drive" your forms.

On a few of my previous projects I found myself creating more form classes than I’d like. And after the 30th one I figured there had to be a better way. I quickly realised that most of the elements within these forms shared similarities to the data type I would use on my database definitions. As I was using Doctrine at the time I figured I could not only drive my database from my mapping definitions, but my forms too.

He shows how post gets into more detail about using the project (configuring caching, other config options).

The project can be found here on github.

Continuing on from the first part of their series, DevShed has posted part two of their "Building an ORM in PHP" series. This latest tutorial focuses on domain modeling (and collection handling).

In that first part, I implemented the ORM’s data access and mapping layers. And as you’ll surely recall, the entire implementation process was pretty straightforward and easy to follow. Of course, in its current state the ORM is still far from a fully-functional structure. We need to add some additional components to it, such as a domain model and the classes responsible for handling collections of entities (remember that the ORM relies heavily on the data mapper pattern to do its business properly).

He stays with his "simple blog" example and shows domain models (based on an abstract entity) for Entries, Comments and Authors. His containers extend the Countable, IteratorAggregate and ArrayAccess interfaces to give them some extra abilities.

On the PHP on Windows section of DZone.com today Giorgio Sironi has posted about a different sort of object mapping than is usually thought of with databases - object-document mapping.

The Data Mapper pattern is a mechanism for persistence where the application model and the data source have no dependencies between each other. [...] But everytime we talk about the Data Mapper pattern, we assume there is a relational database on the other side of the persistence boundary. We always save objects; we always map them to MySQL or Postgres tables; but it's not mandatory.

He talks about two projects, MongoDb_ODM and CouchDb_ODM, that the Doctrine project is working on to help make working with document-driven databases as simple as the usual ORMs. He includes a brief code snippet showing how the feature will work (hint: a namespace of Document instead of Entity). He lists some of the features - including the usual ORM capabilities, support for collections, cascade of persistence - and where you can get the latest code for it (from github and PEAR