Akra’s DevNotes

There's an interesting thread on the ZF mailing list called Default Dirs which deals with where to put your code. It's well worth a read.

I've touched on this before, but thought I'd update my half a dozen readers on my current thinking :)

The manual suggests:

/application
  /models
  /views
  /controllers
/document_root
  /images
  /styles
  .htaccess
  index.php
/library
  /Zend

My current directory stucture currently looks like:

/application
  /models
  /views
  /controllers
  /schemas
  /tests
  config.ini
/scripts
/www
  /img
  /css
  /js
  .htaccess
  index.php
/lib
  /Zend
  /Akrabat

As you can see I'm basically still following the manual, but have tweaked. I have used www rather than document_root because I have a scripts directory and want to emphasise that the stuff in www is for the web server and not for cli. I'm reasonably sure that anyone who has ZF experience could work out what's going on anyway.

Also, you might have noticed that I store config.ini in /app; It seemed like the logical place as there's only ever going to be one of them. I've also got a tests directory and a schemas directory. Schemas is for some work in progress stuff based on the ideas in Ruby on Rails's Migrations system. I'll write about it when I get a chance to actually make it all work!

An interesting question came up about the admin pages of an application. There are two alternatives:

1. "within the site"
2. "separate look and feel"

To be clear, in either case, you would use authentication to determine what the user has access to, but the way you present it is different.

In the first case, the "news/add" action would display a form within the look and feel of the website. i.e. the user doesn't change context, but just gets some extra menu options and features. In the second case, the user logs into a section of the site that looks completely different and has it's own menu system and features. Think about the admin you get for WordPress when writing a post and compare to the main site as an example.

I will probably do both types depending on the site. For community sites, I like to use the admin within the site feel as it makes it much easier for community members to take on roles like forum moderation. For corporate sites, I prefer a separate admin because the designs that customers like are useless for administration!

To implement, I am going to look at using a separate directory for the admin controllers and views as I think it will make it quicker to find the file that I'm looking for when I'm mainting it 2 years later.

Thus, I think something like this will work:

/app
  /models
  /views
    /admin
  /controllers
    /admin
  /schemas
  /tests
  config.ini
/scripts
/www
  /img
    /admin
  /css
    /admin
  /js
    /admin
  .htaccess
  index.php
/lib
  /Zend
  /Akrabat

I'll let you know if it works :)

Just a quick note that the Zend_Config work I've been doing is now in the incubator within the official svn tree!
(Trac link: http://framework.zend.com/developer/browser/trunk/incubator/library/Zend/Config)

Thanks to Darby for sorting this out!

Now everyone needs to go and bash on it and report bugs :)

After discussion with Jayson on the Zend Framework's fw-general list and dealing with some excellent bug reports by Richard (aka OpenMacNews), I've come to the conclusion that the implementation of Akrabat_Config is wrong.

I've redone it as two separate classes with no base class. We now have:

• Akrabat_Config
• Akrabat_Config_ini

Akrabat_Config takes an associative array and provides read only access to it as properties properties . It also implements Countable and Iterator to make life easier. Akrabat_Config_ini loads an ini file and creates an associative array. Therefore Akrabat_Config_Ini only deals with all the handling of the "extends" keyword and nesting using full-stops in the key name. Akrabat_Config only deals with providing data access.

All in all much simpler!

I've updated the code to version 0.8(!):
Akrabat_Config_0.8.zip

I've also sorted out a new version of the Zend_Config proposal, which is now at version 3: Read the rest of this entry »

There's been quite a lot of interesting discussion about my Zend_Config proposal this week. As a result it became clear that the method of extension to multiple sections that I chose in Akrabat_Config v0.6 was not what was envisaged.

I wrote up the four choices that I could see for doing inheritence into a post:

Of course, it all depends on what is meant by "nesting" in the comment
I've quoted  :)  It's likely that I have misunderstood, in which case,
I'll change the proposal.

As I see it the options are:
1. One nest only.
	i.e. can only extend to one section and that the parent
	section may not not extend to another section.
2. Single inheritance nesting.
	i.e. can extend to one section, but that parent section may
	also extend to a parent section.
3. Multiple inheritance, single depth nesting,
	i.e. can extend to many sections using comma separated list
	and each parent section may not extend to another section.
4. Multiple inheritance, multiple depth nesting,
	i.e. can extend to many sections using comma separated list
	and each parent section may also extend to another section.

My personal preference is for (2) as I feel that (1) may be too
limiting, (3) may end up being a debugging nightmare and (4) is a recipe
for confusion!

Fortunately Andi agreed with me, so I've updated the proposal to v2.1 and Akrabat_Config to v0.7 to support (2) rather than (3).

v2.1 of the Zend_Config proposal is: Read the rest of this entry »

A couple of weeks ago I received feedback from the Zend Framework core team about my Zend_Config proposal v1 and have finally found the time to updated the proposal accordingly.

The key points with my comments interspersed were:

- The Zend_Config class shall never modify configuration information in its storage containers

That's ok - I never planned to do writing to ini file anyway.

- The configuration information should only be allow to be modified in memory if a flag is passed to the constructor. This flag will not be allowed to be changed after the object is instantiated.

I have to admit that I hadn't considered the idea of allowing any modification of config data. It's not hard to do though :)

- A top-level section name must be passed to the constructor and the config object will then be locked on this section for its lifetime.

This means that multiple ini files cannot be loaded. i.e. only one ini file is allowed per config object. It simplifies the code too! Note that given that you can do in-memory modification of a Zend_Config object, you could load multiple ini files and overwrite into one Zend_Config object.

- For convenience, configuration information should be available by property overloading and not array access.

This was discussed previously and I hadn't got around to doing it.

- The config object should implement Iterator for easily listing configuration information.

This follows on logically from using property overloading.

- The special inheritence keyword ("include" in the proposal) shall be "extends" as in PHP. Inheritence will be restricted to one section only, i.e. nesting "extends" will be prohibited. This will be detected and an exception raised on violation.

I like the idea of using "extends". Personally, I would have preferred allowing nesting of extends as provides more power. Keeps life simple though.

- Additional config storage containers will be developed so that a variety of configuration file formats can be read. However, the Zend Framework itself will have only one format. This has yet to be decided and is not considered part of this proposal.

I'm sticking with INI for now. As I said in the proposal, extending to other file formats wouldn't be difficult, and we could then use a factory to pick the right one depending on file exension.

v2 of the Zend_Config proposal is: Read the rest of this entry »

Last night was the first meeting of the West Midlands PHP User Group. The phpwm is a mailing list group of around 100 members and now we've placed some names to faces.

Jono Bacon organised the meeting, and Open Advantage graciously hosted it and even provided food! To get us started, we had three short talks:

• David Goodwin of Pale Purple talked about Smarty and separation of business code from display code.
• Elliot of Open Advantage introduced the Eclipse IDE and subversion integration
• Jake Stride of Senokian introduced us to EGS and talked about running a commerical company providing open source solutions.

We then went down the pub which was cool, although the music was a little loud!

Hopefully this will turn into a regular event!

This bug is finally fixed in subversion revision 386 of the Zend Framework. The Zend Framework now as a bug tracker and this bug was reported in tickets #21 and #32. I noticed #36 first though, so attached the correct patch there.

A little later I committed it to subversion and that bug is gone!

Next up is unit tests for the Zend_Db tree. I've created ticket #36 to track my first attempt at getting some unit tests for Zend_Db_Adapter_Pdo_* working. Note that you need the insert() fix for the tests that are attached to the ticket to work! Read the rest of this entry »