Framework discoverability

I answered a question on http://programmers.stackexchange.com recently and I’d like to expand a little on my answer here.

Up until mid 2010 I used my own framework for all my freelance and personal development work, it had served me admirably over the years and in fact to this day it is still being used by one of my previous employers. I was part way through rewriting it to serve me for another few years.

Even though I had plenty of experience with other frameworks, Zend, Yii etc I still tended to use my own because it was so rapid and had never got in my way or not been fit for purpose.

One of the main reasons behind the full rewrite was Dlayer, my framework/library was very suited to building websites/shops etc but it wasn’t really suitable for Dlayer, Dlayer doesn’t really have a structure similar to traditional sites or apps.

I was rebuilding some of the core classes one evening and said to myself “what are you doing Dlayer isn’t going to use this class for months, if ever.”

I decided to prioritise, rather than rebuild my framework I was going to use an existing framework and build Dlayer, I was effectively just ‘wasting’ time.

As I stated at the start this came up because I answered a question on http://programmers.stackexchange.com about Zend being difficult and it got me thinking.

When I started using the Zend Framework the biggest issue for me was lack of discoverability, far too many of the methods/classes rely on data array to set their options. You end up spending ages either trawling through the code or even worse the online manual attempting to work out what keys you need in the array. The Yii framework takes this concept to the extreme, almost everything is driven by magic arrays.

There is nothing wrong with named params and setter methods, in fact from my point of view if a class needs a large array to set it up something is wrong.

Of all the options out there I still think the Zend Framework is generally the best fit, for me anyway but there is quite a steep learning curve.

Status update

Seeing as I haven’t posted for a while I figured it would be wise to provide a status update on how Dlayer development is going and what I have been doing for nearly four months

I got married at the start of September, so far so well. We went on honeymoon a few weeks later, med cruise in case you are interested, that takes us to mid October, 6 weeks left to account for. The remaining part of October was very quiet, I spent a couple of weeks looking for a new contract and also acclimatising myself to married life. November was business as normal, I just didn’t reach a point at which there was anything to write about.

Dlayer

If you read through my blog it wouldn’t surprise me if you said you were confused with where I am with the development of Dlayer, how have we gone from Milestone 11 to Phase 7?

As of today I am almost complete with Phase 7. In April, 2011, I reviewed the progress of Dlayer with Dan my project manager/tester etc. The consensus was that we needed to split the app, Dlayer was becoming far too complicated to complete within a reasonable time period with such a small team.

We decided to break Dlayer up into two apps, a designer and the main app, Dlayer. Dlayer is the full version of Dlayer, it is what I envisioned years ago, Dlayer designer is a more realistic limited app which is primarily aimed at showing what we want to do with Dlayer. Don’t take from this that the Designer is just a demo or preview, it is going to be a complete app in its own right.

Still Phase 7?

In August I posted that Phase 7 was almost complete, why then am I still not finished? The answer to this quite simply I’m a developer, I can’t help but to keep improving things.

The real reason is a little more complicated. One of my major goals for Dlayer was that it would be incredibly easy for developers to extend by adding new design/content tools. Whilst finishing Phase 7 I reviewed my code and decided that I wasn’t happy with the way some of the tools were created, too much code for central tools was part of the main app, it wasn’t in separate modules.

I decided to rebuild all the tools making them slightly more modular, each one isn’t far off being a complete package, the more important point is that they are all built in exactly the same manor. The current tools are all first party tools, as such they aren’t completely modular because they don’t need to be, you can’t use Dlayer without them but the core principle I have used to create them can be extended to allow the creation of tool modules.