On the Pineco.de blog there's a new post for the Laravel users out there showing you a simple way to integrate translations handling into your models. This functionality allows you to more easily build multilingual applications without having some of the overhead of a separate translation framework.

Making you models translatable could be an issue, especially if you are running an application that is multilingual. For static texts, we can use the built-in translation engine, but for models, we need to solve a more complex issue. Let’s take a look at a simple yet flexible solution.

While the post starts with a recommendation to use a full package if you need a more robust system, it quickly moves into the simpler structure they'll be defining. The tutorial describes the "translation mechanism" from a high level and includes the code to create the database table for holding the translated content. With that in place, next up is the model to connect the application with the table and a trait to house the translation logic. This is then used directly in the template (as a translation property) to fetch the translated version of the content.

On the SitePoint PHP blog there's a new post from Younes Rafie looking at polymorphic relationships and how they're used in the Laravel Eloquent functionality to relate tables and entities to one another.

While I was working on an application for a client, I had to implement a new module that entails the following:

• Users ask for a budget quotation for a certain task.
• Every task has a location.
• Professionals can subscribe to different zones.
• A zone can be a region or a city.

Now, let’s neglect the core application and try to implement this single module to see what we can achieve here.

He starts off by scaffolding out a basic Laravel application, setting up the database configuration and creating the migrations for "Zones", "Regions" and "Cities". He looks a bit more in-depth at how the models were created and how to create the methods relating one to another. The relation goes "through" the zones handling, so they use the "morphedByMany" and "morphedMany" to tell Eloquent how to make the connection. He then shows how to use the relations in your code and some of the collection helper methods to make it simpler to get just the data you want.

Adam Wathan has a recent post to his site showing you how to stub out your Eloquent relations in a Laravel application for use in your testing (rather than hitting the database directly).

When you’re trying to test methods on an Eloquent model, you often need to hit the database to really test your code.

But sometimes the functionality you’re testing doesn’t really depend on database features. Is there any way to test that stuff without hitting the database?

He starts with a look at the more traditional method, using the models normally and testing with the database. He includes a simple test and class showing a basic "song duration" integer response. He gets into a bit more detail on how the Eloquent code grabs the data it needs when a relation is accessed (hint: not a separate query) and how to update the test to mimic the eager loading of the duration information. He ends the post by pointing out that "nothing is free" however as, if the underlying database implementation changes, the test would start to fail regardless of it not using the database.

Davey Shafik has continued his series of posts with advice about growing a community around your product/open source libraries. In his first post he talked more about how to engage the community. In this latest post he talks about the role of "evangelists" in community relations (and why he dislikes the term).

The role of the Community Builder is to sell you on the idea of the company and the product. Not necessarily to sell you the product. Often times what we’re selling are not bought without some decision making process behind them, so a sale is not going to happen then and there anyway. Provide the education, and build the trust, and the sale will happen.

Davey then talks about why he hates the term "evangelist" and how it seems to relate more to "fanatic" than "advocate". He then gets into what he sees as the role of an advocate, including the role honesty plays and selling the customer on the right product. He then turns it around and talks about the other side of the role - advocating for the customer back to the rest of the company. Finally, he talks about two other kinds of advocacy that should also be included in the role: advocating for the community/their input and for yourself (finding a product you can be passionate about selling).

The SitePoint PHP blog has posted a list of seven customer relationship management tools (CRM) that play nice with Drupal, a popular PHP-driven content management system.

Whether you want to call Drupal a CMS (Content Management System), a CMF (Content Management Framework) or a CMSomething, the ‘C’ always stands for Content. Content is where Drupal shines and is what it’s designed for. [...] When an organisation is at a stage and mindset that they also want to manage their contacts and interactions effectively they will often need tools designed specifically for that function. These are generally referred to as a CRM, which stands for Client Relationship Manager or Constituent Relationship Manager, depending on the sector (For-Profit or Not-for-Profit respectively)

[...] What has a CRM got to do with Drupal? Nothing directly, but indirectly if you’re looking to streamline your business operations and automate the ways people can interact with you, your CRM will need to work well with your website. [...] In this article, we will look at several of the big players in the CRM space that work well with Drupal, how they integrate or how developers can get them to integrate.

They start with a list of five of the seven options:

• Roll it yourself
• RedHen
• CiviCRM
• Salesforce
• Sugar CRM

They also provide a few other options combining a few technologies: Microsoft Dynamics and BlackBaud or Nation Builder and Salsa. Links and a brief summary of the project are included for each item in the list. He ends with a few tips about the actual integration, including the use of the CRM tool's API or using the Migrate Drupal module.

Anthony Ferrara has written up a great post on technical debt, relating it to terms that might be a bit more "real world" for many out there - corresponding financial problems.

Lately, I've found myself in a number of discussions about Technical Debt and how it applies to project development. Overall, I think it's a very powerful tool that -- when used wisely -- can be a great asset to any team. It seems to me that most of the people that I've been talking to really don't agree, and see Technical Debt as a plague that should be eliminated at first sight. So, I figured I'd share my opinions, and see what you think...

He talks about a few different kinds of technical debt described by the names of their financial counterparts:

• the Payday Loan (a current concession for the sake of time)
• a Mortgage (making small parts, payments, of a whole without consideration of the overall picture)
• a Credit Card (not knowing the need causes a sub-optimal solution)
• Hidden Debit (an unclear understanding of the full scope of the debt)

He also touches on two other topics - how to find and get rid of the Hidden Debt your project might have and a common misconception that technical debt doesn't exist in an aglie world.

On PHPMaster.com there's a recent tutorial introducing the concept of a "domain model" and showing how to create them in PHP (manually, not inside of any ORM or database solution).

First off, creating a rich Domain Model, where multiple domain objects with well-defined constraints and rules interact, can be a daunting task. Second, not only is it necessary to define from top to bottom the model itself, but it’s also necessary to implement from scratch or reuse a mapping layer in order to move data back and forward between the persistence layer and the model in question.

They include an example of a set of domain models tat relate to one another - a blog setup with posts, comments and users. They show how to create the AbstractEntity to handle a bit of the magic behind the scenes, an example "Post" and "Comment" models and how they can be put to work creating some posts and appending comments. A little bit of markup is included to output the results.

In this new post to the PHP 10.0 blog today, Stas talks about duck typing, a method that lets the code decide the functionality to use rather than a direct relation to a parent.

Well, if you are into duck typing style of programming, it may be interesting for you to have an object that implements certain set of functions, but not necessary declares it at class definition. Languages like Smalltalk do it all day along, so why PHP couldn't?

His example defines an interface Cow and a class MooingGrassEater and a function, CowConsumer, that does the work. A classname is passed in and an instance of that class is checked with "implements" rather than "instanceof" to see if it uses the Cow interface. He points out a place where PHP itself uses something similar in user defined streams.

Tobias Schlitt has pointed out a new article he's written up that acts as an introduction to the features of the new ORM component of the eZ Components application framework - the PersisteneObject.

For me the coolest feature of PersistentObject is, that the component does not require you're ORM enabled classes to inherit from a certain base to allow your objects to be stored in a database (made persistent).

This new object gives you a "wapper" of sorts to make any of the pre-existing objects in your application persistent. Check out the article for more.

Tobias Schlitt has pointed out a new article he's written up that acts as an introduction to the features of the new ORM component of the eZ Components application framework - the PersisteneObject.

For me the coolest feature of PersistentObject is, that the component does not require you're ORM enabled classes to inherit from a certain base to allow your objects to be stored in a database (made persistent).

This new object gives you a "wapper" of sorts to make any of the pre-existing objects in your application persistent. Check out the article for more.