Framework Awesome

We’ve pushed some super enhancements over the last few weeks and I’m really pleased with them, but there’s more that I find myself wanting to do: mainly conveniences, to improve developer performance, but some of it to improve application performance too.

1. JSON syntax for EddyModel::get()

I’m desperate to optimise models in Eddy. At the moment EddyModel::get() accepts an array of query parameters. This provides certain benefits to the security-conscious developer - we can do automatic escaping of parameters for instance. But it’s arduous to write out.

Other frameworks use entirely new languages, chaining of methods etc etc but I really like the way some of the NoSQL datastores use JSON syntax for querying and I think we can use it here too. Why?

JSON is easy to read and write by humans and machines. We get all the benefits of distinguishing all of our parameters and hopefully save the developer a little bit of time. The only downside I can think of at the moment is that there will be a little overhead in parsing the JSON out to a PHP array. But this could be pretty negligible.

JSON is becoming something of a standard in various places, so I think it might make quite a nice solution here. It also makes our querying API easily extensible without troubling developers with new function calls etc. What do you think?

2. Putting Eddy base classes in their own namespace

As we’ve made a whole-hearted move towards namespaces now, I wanted to embrace them in the core. Any new classes will be namespaced, but existing classes carry a bit of a weight problem with them, because they’re already being used in a number of projects.

We are going to move ahead with this, meaning that all base classes that currently start with ‘Eddy’ will be moved into core/lib/Eddy/. To access them you will need to call them through this namespace. The only challenge this really represents is backwards-compatibility.

While we’re not overly concerned about that for Eddy at the moment as there’s not a lot of users, we need to get into a habit of doing it, as there ae more and more public projects out there relying on the core.

What we will do for the time-being is create aliases to these namespaced classes, retaining the original class names. But I would still like to know how you feel about this move!

Importantly, this won’t include the Eddy static class as this is conveniently global.

3. Extra classes

Before namespaces, we had a number of extra classes residing outside of the core/lib/ folder i.e. helpers and extras. Helpers are now namespaced in core/lib/Helpers/, but extras are another story. These are classes that we occasionally use with Eddy, but are not core to its functionality - they could be viewed as helpful modules or plugins. However, they’re still potentially useful in your app.

So far we’re thinking of creating a new repository for these libraries (or individual repositories for each one). You can then get the ones you want and place them in your app/lib/ folder as needed.

4. Improved queries in models

When your models build queries for collecting object data, at the moment they do a ‘SELECT *’. This is great for making sure you’ve got all the data from the table for this instance, but it can be pretty heavy.

Quite often we find ourselves optimising queries by writing the query manually; only getting the fields we really need. But this all-or-nothing approach is inconvenient. So we’re thinking of a way to only get what we need without losing all of the benefits of using models.

Would love to hear your thoughts on any of these issues. As always, feel free to tell us what you’re using Eddy for and get in touch if you need any help!