Separation of concerns is a design principle, and states that each part of a software addresses a separate concern. Different patterns and abstractions can be used for that like MVC, DAOs and repositories.

Repositories help in the abstraction of the data layer. It provides an interface for retrieving data, independent of the implementation, acting like a collection of objects.

In Nestor-QA I had implemented repositories using some Java code I had in my mind, without paying too much attention to the abstraction layers. Two weeks ago, while working on some complicated issue in Nestor I noticed that the repositories in Nestor had been implemented using the Eloquent classes.

Eloquent is a library used in Laravel for data abstraction. It provides access to databases like MySQL and SQLite, kind like DAOs (and sometimes like repositories too). However, for Nestor being a test management tool, we are trying to be platform and framework independent. Here’s the old repository code in action:

class DbProjectRepository implements ProjectRepository {

    public function all()
    {
        return Project::where('project_statuses_id', '<>', 2)->get();
    }

    // ...

}

As you can see, we were returning the result of the get() method from Eloquent. Another big mistake was using these objects in the views. In the end we were not only using data layer elements in the wrong place, but we also had many queries to render an UI.

abstract class DbBaseRepository extends BaseRepository {

    protected $model;

    public function __construct($model)
    {
        $this->model = $model;
    }

    public function all()
    {
        return $this->model->all()->toArray();
    }

    // ...
}

After searching for a while, I found a nice example of a class design for repositories, where the return type is always an array. In the views you will have the array and keys, and in case someday you decide moving to another framework, you can leave the views unchanged (hopefully :-). Neat, no?

Happy hacking

Here’s the list of the cool things that happened at TupiLabs since last Sunday.

• Paskuale backend services running in production for the first time. Just have to finish the dictionaries and remaining tools to see the first results.
• Added more features to a Hostel system we’ve been working on
• https://github.com/ludovicchabant/bolt80.com/pull/5
• https://github.com/ludovicchabant/PieCrust/issues/90

We are working for you

Have a great week! :-)

Here’s the list of the cool things that happened at TupiLabs since last Sunday.

• Mother’s week summary post in SLBR
• Migrated kinoshita.eti.br to PieCrust + Ant, like TupiLabs website.
• Blog post explaining how to use CodeIgniter + PieCrust
• Apache UIMA + NLTK + OpenNLP prototype.
• Started setting up Paskuale backend services in production

We are working for you

Have a great week! :-)

In of our largest web applications is Speak Like A Brazilian. We’ve been working to Open Source it, but first we have to double check the security aspects of this procedure, as well as review the source code.

Recently we added a blog to Speak Like A Brazilian. Navigating in the Internet, we found many tutorials for adding a blog engine to web applications using CodeIgniter.

Since the blog is limited to moderators or developers, we decided to use a static content generator, preferably one that supported Markdown. We opted for PieCrust, and after few tests we were delighted by the flexibility and modularity.

While writing the last post, I had some trouble trying to escape a Twig macro when using Geshi for syntax highlighting. Here’s the trick to escape it: raw.

The raw Twig tag prints the subsequent tags without interpreting it.

{%geshi 'twig'%}
{ %raw%}{% macro button(...) %}{ %endraw%}
<p>Some random HTML code...</p>{% raw%}{% endmacro %}{ %endraw%}
{%endgeshi%}

We had to add an extra space between { and %. Can you figure out why? :-)