Mirmo Dynamics - Coding

having fun with vim, an event tracker

Geoffrey — Sun, 08 Mar 2009 21:16:00 +0100

The idea of this script came by realizing that the main reason I (almost) never fill my timesheet, is because I just forget it. How easier could it be if my editor (namely vim) could fill it for me ? Or at least, help me fill it. This script is meant to help this process. It will hook to every configured event (in the code below, BufRead and BufNewFile) and add a log line to the log file. Easy heh ? Of course, the script it self won't be of much use, I'll have to add some more events to track as well as writting some kind of frontend for it, with reporting & all.

if exists('trackloaded')
  finish
endif

" list of autocmd events:
" http://www.vim.org/htmldoc/autocmd.html#autocmd-events
let trackevents = ['BufRead', 'BufNewFile', 'BufEnter', 'BufWrite', 'BufLeave']
let trackfile   = '/tmp/timetrack.dat'
let trackloaded = 1

for event in trackevents
  execute 'autocmd '.event.' * call Track("'.event.'")'
endfor

unlet event

function Track(event)
  let l:filename = @%
  if l:filename != g:trackfile
    if match(l:filename, '/') != 0
      let l:filename = getcwd().'/'.l:filename
    endif
    silent execute '!echo `date +\%s` '.a:event.' '.l:filename.' >> '.g:trackfile
  endif
endfunction

You might note from this snippet that I'm not very comfortable with vimscripting :-) If you have a better way of doing this (I'm thinking mostly about the file writting here), don't hesitate to tell me.

Replacing short tags with proper PHP tags

Geoffrey — Thu, 29 Jan 2009 10:37:00 +0100

This is a little script I made to get rid of those damned short tags.

[php]
<?php

while ($file = trim(fgets(STDIN)))
{
  $content = file_get_contents($file);

  $search  = array('/<\?=/', '/<\?(?!php|xml)/');
  $replace = array('<?php echo ', '<?php ');

  if ($content != ($new_content = preg_replace($search, $replace, $content)))
  {
    file_put_contents($file, $new_content);
  }
}

Just put this in a file, short_tags.php for example, and run something like:

$ find . -name "*.php" | php ./short_tags.php

I would have done it with sed, but it doesn't seem to support PCRE, and I don't know how to do negative lookahead (the (?!php|xml) thingy) with POSIX based regexp (if it's even supported) :/

UPDATE: Actually, POSIX Regexps DO support negative lookahead (as well as positive lookahead and lookbehind) with the same syntax as PCRE regexps. But grep doesn't use POSIX regexps, it uses things called BRE and ERE that I've never heard of before. Too bad.

Why I switched from ZF

Geoffrey — Mon, 24 Nov 2008 23:50:00 +0100

Please note all the reasons I'm about to give are the reason I had at the time I quited ZF, that's like 6 months ago or so, so be aware that things may have evolved, and since this is not a rant, I won't even check if they actually changed (as I really don't give a damn). Also, I'm writing this post only because I said I'd write it, I'm not trying to convince anyone, nor am I trying to start a discussion about the pros and cons of ZF.

First, I think the Zend Framework is a bit complex. That's quite vague for a framework of that size, but let me explain. There are a lot of things to know and do before you can even think of really working on your project. Zend Framework has a lot of classes, and you better know a lot of them to get productive.

Which lead to another problem: configuration over convention. This concept is deeply rooted inside the framework, and I think it's just wrong (although I know it's a pro for some people). It forces you to know instead of just being able to guess (and I think knowing how to guess is very important for a developer), so you just can't install the framework and start working ootb, you have to read docs (well, you always have to read docs, but), you have to read A WHOLE FUCKIN LOTS OF DOCS, and god, it's boring and greatly time-consuming.

Time-consuming, because the documentation is poorly structured. I've always found it hard to find exactly what you need in the documentation. Not sure why (and that's not a point I will expand on, since this is very subjective, and most of other frameworks have equally poorly structured doc).

Now my main point: Zend Framework is nothing more than a Zend sponsored PEAR. You have no tools to ease or speed application development, no coupling between components (yet again, I know this is a pro for some people ;), no code generation, no easy database management, no task handling, etc, etc. So what's the point using a framework if he doesn't really help you developing ? Not much if you ask me (and if you're reading this, we could assume you asked).

Add to all this poorly written components (some of them don't even follow the coding standard !), stupid decisions (i18n exceptions anyone ?) and marketing-drived release policy, and there you are, one less Zend Framework enthusiast (not that it matters anyway).

So thinking about all that, there's a single word that describe exactly why I've been disappointed by ZF: expectation. Zend Framework is just not meeting my expectations, it doesn't fit my needs, that's why I switched to another framework, that, for now, I'm fully satisfied with.

About the self keyword in static methods

Geoffrey — Mon, 14 Jul 2008 16:04:00 +0200

While setting up a test server for some software I wrote at the office, I eventually noticed the following notice:

Notice: Use of undefined constant self - assumed 'self'

That surprised me, because 1) I though self were some kind of "superglobal" constant or a special token of the parser, always automatically available in a static method and 2) the code works. So what's up in there ? Let's make a simple test:

<?php

class foo {
	static public function bar() {
		var_dump(is_callable(array('self', 'foobar')));
		var_dump(is_callable(array(self, 'foobar')));

		var_dump(class_exists('self'));
		var_dump(class_exists(self));

		self::foobar();
	}

	static public function foobar() {
	}
}

foo::bar();

Executing the above code will yeld the following result:

bool(true)

Notice: Use of undefined constant self - assumed 'self' in /home/geoffreyb/test.php on line 6
bool(true)
bool(false)

Notice: Use of undefined constant self - assumed 'self' in /home/geoffreyb/test.php on line 9
bool(false)

What do we learn here ? Not much actually. It seems like self as a constant is only available when used with the scope resolution operator, aka double-colon or paamayim nekudotayim. When you want to use it in, for example, a callback definition, use a string representation of self:

<?php

is_callable(array('self', 'bar'));
call_user_func(array('self', 'bar'));

Which, while making absolutely no sense at all, works. Another way to get around this is to use the get_class() function that, without any argument, will return the name of the class you're currently in (foo in my example).

After a bit more investiging, I found out that there is nothing special about the self token, which is actually a string token. You can check this very easily with the following code:

<?php

class foo {
	static public function bar() {
		self::foobar();
	}
}

var_dump(token_get_all(file_get_contents(__FILE__)));

Somewhere inside the output, you'll find the following piece of text:

  array(2) {
    [0]=>
    int(307)
    [1]=>
    string(4) "self"
  }

And the token id 307 is resolved by token_name to string.

Zend Framework 1.5.1 PEAR package is available

Geoffrey — Mon, 31 Mar 2008 17:08:00 +0200

A little late sorry, but ZF 1.5.1's package is now ready.

ruby: url_to_constant

Geoffrey — Thu, 27 Mar 2008 23:04:00 +0100

A small bit of ruby to get a constant from an URL:

[ruby]
require 'uri'
def url_to_constant(url)
	return URI.parse(url).host.gsub(/^www\./, '').capitalize.gsub(/[^a-z][a-z]/i) { |m| m.gsub(/[^a-z]/, '').upcase }.constantize
end

Nothing exceptionnal here, just a pretext to post something.

Zend Framework 1.5 PEAR package is available

Geoffrey — Sat, 22 Mar 2008 18:19:00 +0100

The long awaited 1.5 version of the Zend Framework has landed for some days already, and here comes its pear package. Please note the api version changed to 1.5 in this package.

Plugin "related by tags" pour dotclear 2, deuxième

Geoffrey — Mon, 10 Mar 2008 21:48:00 +0100

Après de longs mois d'attente, le related by tags nouveau arrive enfin ! Au menu des réjouissances, une interface de configuration, ainsi qu'un widget font leur apparition. Vous disposez donc désormais de deux manières d'afficher les billets liés, directement en modifiant le template comme avant:

{{tpl:include src="_related_by_tags.html"}}

ou tout simplement en activant le widget correspondant, que vous pouvez configurer comme vous l'entendez. Bien sur, ce widget ne s'affichera que lors de la visualisation d'un billet.

Au chapitre des fonctionnalités / bugfix manquant(e)s, on notera le bug lié à l'utilisation de postgresql, ainsi que la traduction française, qui sera pour plus tard.

Encore une fois, n'hésitez pas à poster tous vos commentaires ici même.

Zend Framework 1.0.4 PEAR package is available

Geoffrey — Wed, 27 Feb 2008 11:17:00 +0100

The package for the last 1.0.x release, 1.0.4, is now available on the phpmafia pear channel. Please report any issue in the comment of this post. The Zend_Locale's xml bug should now be fixed (they are now considered as php and thus put at the right place, which is not the best way to fix the bug I guess but at least it should work for now).

yaml, activerecord and acts_as_nested_set

Geoffrey — Sun, 02 Dec 2007 16:41:00 +0100

I used to use this yaml_to_ar lib from christophe to load categories tree into my database, using acts_as_tree in the model that was perfect. Arrived the time when I felt the need to use acts_as_nested_set instead, for which I had to fill the lft and rgt columns. So I just rewrote the yaml_to_ar piece of code (put this in lib/yaml_to_ar.rb):

[ruby]
require 'yaml'

class YAML_to_AR

  def initialize(file, model)
    @data = File.open(file) { |yf| YAML::load( yf ) }
    @model = model
  end

  def process(data = @data, parent = nil)
    if data.is_a? Array
      data.each do |val|
        process(val, parent)
      end
    elsif data.is_a? Hash
      data.each do |key,val|
        parent = @model.create(:title => key)
        process(val, parent)
      end
    elsif data.is_a? String
      parent.add_child(@model.create(:title => data))
    end
  end

 end

This should handle both acts_as_tree and acts_as_nested. To ease things a bit further, I also wrote a rake task (to drop in lib/tasks/db_load_categories.rake for example):

[ruby]
namespace :db do
  desc "Loads categories defaults data"
  task :load_categories => :environment do
    require 'lib/yaml_to_ar'
    Category.delete_all
    categories = YAML_to_AR.new('db/categories.yml', Category)
    categories.process
  end
end

Now I just rake db:load_categories, and voila !

my first rails plugin: named_resources

Geoffrey — Wed, 28 Nov 2007 13:00:00 +0100

It's a simple plugin (2 lines of code beside class and modules declarations) which allows routes created via the map.resources mechanism to be customized. Say you have the following map:

[ruby]
map.resources :members

It will generate routes like:

/members
/members/:id
/members/new

No say you want to i18n your app, in french for example, what do you do ? You just can't out of the box. This is where my plugin enters into action, just add a :route_name parameter to the map.resources call and you're set:

[ruby]
map.resources :members, :route_name => 'utilisateurs'

will generate routes like:

/utilisateurs
/utilisateurs/:id
/utilisateurs/new

It shall also work for nested resources, although I did not test that.

The code is actually pretty simple:

[ruby]
module ActionController
  module Resources
    class Resource
      def path
        route_name = @options.include?(:route_name) ? @options[:route_name] : @plural
        @path ||= "#{path_prefix}/#{route_name}"
      end 
    end 
  end 
end

To install just use script/plugin:

script/plugin install http://tools.assembla.com/svn/riskle/rails/plugins/named_resources

or to install as an svn:external resource:

script/plugin install -x http://tools.assembla.com/svn/riskle/rails/plugins/named_resources

Accessing raw post data in a controller

Geoffrey — Wed, 21 Nov 2007 12:03:00 +0100

For some reason, $HTTP_RAW_POST_DATA does not seem to be set inside an action controller. You'll have to use the php://input stream wrapper to access raw http post data:

[php]
$raw_post_data = file_get_contents('php://input');

Extending Zend_Controller_Router_Route: the singleton problem.

Geoffrey — Mon, 05 Nov 2007 14:37:00 +0100

Today I ran into an issue while extending Zend_Controller_Router_Route. I wanted to add a little path pre/post processing in the match() and assemble() methods, so I just extended the Route class to add my tiny bits of code into the methods. Except it did not work at all. After a few debuging, it turned out that the Router uses Zend_Controller_Router_Route::getInstance() to retrieve a route object, which uses a new self(); statement to instantiate the route object. Problem is that self always refers to the current class definition we're in, if the method is called from a child class, without being overloaded, self will refer to the wrong class.

Example:

[php]
class Foo {
	public static function getInstance() {
		return new self;
	}
}

class Bar extends Foo {}

var_dump(Bar::getClass());

echoes something like:

object(Foo)#1 (0) {
}

Which is fscking wrong IMHO. A quick workaround is to overload the getInstance method, which is what I call pretty annoying as it does not follow the DRY principle.

How I use the Zend Framework

Geoffrey — Mon, 22 Oct 2007 13:39:00 +0200

Having started a few applications using the Zend Framework, I came out with a few practices that I tend to use over and over. In this post I'll quickly expose some of them and explain why I do things the way I do them. As you'll notice, most of them are already widely known and used over the ZF developer's community. Please remember that these practices are just what I do, and come with no garanty at all to be best practices.

Directory structure

First thing to work out when starting a new Zend Framework powered application, at least if you decide to use the ZF's MVC component, is the application's directory structure. Here is the one I used, which is a slightly modified version of the official recommended structure. This is essentially a standard modular structure with all directories needed to store various additional data from your application.

application/
	cache/
	config/
		application.ini
		routes.ini
	data/
	layouts/scripts/
	library/App/
	logs/
	modules/
		default/
		user/
document_root/
	css/
	images/
	index.php
	js/

As you can see, I have many directories, each dedicated to a specific file type. This has many advantages, such as always knowing where to find what you're looking for or easily process files of a certain type (think grep foo logs/*). Also, I name my directories explicitly. I used to call the config directory etc, which is the directory holding most configurations files under UNIX systems, but it may not appear that clear to non-UNIX user, while config is clear enough for everyone.

Another point you might notice is the that all applications files and data are placed outside the document_root. This is done to avoid unwanted access to such resources. While this is the best way, in my opinion, to do, it may not always be possible (like when you have no control on your actual DocumentRoot. In this case, you may consider having the following structure:

application/
	cache/
	config/
		application.ini
		routes.ini
	data/
	layouts/scripts/
	library/App/
	logs/
	modules/
		default/
		user/
	tasks/
css/
images/
index.php
js/

Then you can deny any web access to the application/ directory with the following htaccess rules:

<Directory application>
    Order allow,deny
    Deny from all
</Directory>

Did you say modular ?

Yeah, I said it actually. Modules in Zend Framework are groups of controllers (along with their corresponding views and models) which sits in their own namespace. One could argue that module's primary goal is to ease code re-use, but I personnaly dunno, as I personnally still have not seen such a use of modules. The drawbacks of re-usable code is that it needs to be abstract enough to fit ant particular situation or so. In this context, I only have a single separate module alongside the default one: the user module. It has Index and Auth controllers, respectively used to perform CRUD and login/logout operations.

Having re-usable modules implies that all modules containes its own models, or at least, knows where (ie, in which other module) to find its required models. There comes Xend's model loader. This is an action helper which ease the load of models inside controllers, like:

$this->_helper->modelLoader(array('MyCoolModel', 'MyOtherModel'));

Easy heh ? The bad point with this helper is that it is restricted to, or at best tricky to use outside, action controllers. That is why I developped my own library loader which I shall present in another blogpost soon.

Models naming convention

Using the Xend's model loader trained me to adopt what I consider a good model naming convention, basically, it just follows the controller's conventions, that is, prefix the model name with the module's name, so that for example my user model is named like User_Users (the first User is the module name, the second Users is the ucfirst'ed tablename). whenever I need to have row specific model I just postfix the whole model name with _Row. It gives the following directory architecture:

modules/user/models/
	Users/Row.php
	Users.php

I'll eventually load User_Users_Row from User/Users.php with a simple require:

[php]
require_once dirname(__FILE__).'/Users/Row.php';

Personal library namespace

A recurring question from ZF beginners is to know where they should put their own library classes. The answer is pretty simple actually. You just create your own library namespace alongside Zend's. Let's say you wish to extend Zend_Db_Table_Abstract to add your own logic. The first thing to do is to choose the name of your namespace, we will use Foobar as an example, because this is a cool name. Your class will be named like Foobar_Db_Table_Abstract, and located in Foobar/Db/Table/Abstract.php, which in turn should be located anywhere in your include_path. So you could have the following directory structure:

application/library/
	Zend/
	Foobar/
	Riskle/

Just remember ZF's naming convention: from the filename, strip the .php, replace slashes (/) with underscores (_), and you've got the class name. Simple heh ?

App_ library namespace (App_Controller_Action, etc)

Additionnaly to my personal library namespace, I also have a special App namespace, which I always locate into application/library/App. This namespace principally provides two classes, App_Controller_Action and App_Db_Table_Abstract, which basically extend respectively Zend_Controller_Action and Zend_Db_Table_Abstract. All my controllers and models then use the App_ namespace as a reference, so that I can easily change the base class for all my controllers / models as easily as changing the parent of the corresponding App class.

Using third party components

Using ZF compatible components is just easy as dropping them in your include path. By ZF compatible, I mean following the ZF class naming convention. Just make source it's in your include_path, and you can start using them right away. Components library I use includes:

Xend's layout component
Some components from Naneau's library
My own library, Riskle (you'll need an assembla account)

I put them in a particular path (~/share/php/) which I add to my include path.

note: Some dikdiks tend to store third-party in application/library/ instead of a completely separate place. This problem looks a lot like dynamically linked vs static binaries. With static binaries (in our case, storing all in application/library/), you don't have to care about dependencies, as every single needed line of code is shipped with your application. This ease redistribution and installation a lot, but makes your download larger. You also have to manage yourself dependencies upgrade (which in turn save this hassle from the end-user). With dynamically linked applications, you avoid duplicated code by forcing the use of a global, site wide, code repository (generally /usr/share/php on unix systems). You also transfer dependencies handling to the end-user (and/or the packaging system). Really, this is a choice to make yourself I think.

Things get a little bit more complicated when the components does not follow the naming convention. What I do in this case is just puting them into a separate directory tree called vendor/, which I don't forget to add to my include path of course, then I just manually includes need files. We could have done a one-to-one match between the component's public classes and custom well-named classes, but it's much of a hassle for the benefit I think.

That's all folks !

Well that's all for today. I'll try to write some more in the future about application building with the Zend Framework, there are still a lot of things to be said, invented, and discovered :-)

Plugin "related by tags" pour dotclear 2

Geoffrey — Thu, 04 Oct 2007 20:50:00 +0200

update: nouvelle version disponible

Allez hop, j'ai codouillé rapidement aujourd'hui un plugin dotclear 2 pour afficher une liste des billets ayant le ou les mêmes tags que le billet en cours de lecture par l'internaute. Il est téléchargeable dès maintenant sous forme d'archive tar gzipée ou directement de package dotclear. Pour l'utiliser, rien de plus simple, il suffit d'ajouter le tag suivant dans votre template, à l'endroit où vous souhaitez afficher la liste des billets:

{{tpl:include src="_related_by_tags.html"}}

Et voilà c'est tout :-)

Bon par contre, il faut faire gaffe a comment on tag ses billets (genre pour celui là j'ai preferré ne pas le taguer php histoire d'avoir des résultats plus pertinents).

ps: si quelqu'un connait un moyen d'éviter d'avoir a rajouter un bout de code au template je suis preneur (mais j'ai la flemme de chercher là tout de suite).

PDO not throwing an exception when it should

Geoffrey — Mon, 01 Oct 2007 17:40:00 +0200

Today I ran into an issue that I already ran into a few weeks ago when I did not have time to dig up, but today I had this time (this plus it's a really annoying issue as you'll see). The main symptom is that PDO does not throws exceptions when you'd expect it to. It's very annoying. The reason, in my case, seems to be that I am querying an old mysql (3.23.x in my case but any 4.x will do according to this bug report). I was not able to find any info from google, so I'm posting this here so that people know :-)

New home for pagination component documentation

Geoffrey — Mon, 01 Oct 2007 12:44:00 +0200

For those caring, I just posted some quick documentation for the pagination component at my assembla space. More docs will follow (including extensive phpdoc docblocks I hope).

Zend Framework 1.0.2 PEAR package is available

Geoffrey — Sun, 30 Sep 2007 16:21:00 +0200

A PEAR package for the 1.0.2 version of the Zend Framework is now available from the PEAR PHPMafia channel. As usual, to install just issue the following:

[bash]
pear channel-discover pear.phpmafia.net
pear install phpmafia/Zend

Bugfixes release of Zend Framework pagination component

Geoffrey — Sun, 30 Sep 2007 01:28:00 +0200

I just released on riskle's assembla space a new version of my pagination component for the Zend Framework which you can download right now:

Riskle Paginate r122

This release fixes a nasty bug in Riskle_Db_Table::fetchCols which prevented from retrieving the right count of cols involved in the query.

The table component has also been slightly rewritten following Erik's suggestion to move the parent mapping into _fetch. The parent mapping itself has been improved to allow "multi level" table joining. This will be best explained with an example:

Say you have three table, Foo, Bar and Quux, and you would like to execute the following query:

[sql]
SELECT * FROM Foo JOIN Bar ON Foo.bar_id = Bar.id JOIN Quux ON Bar.quux_id = Quux.id

This is now possible with the following mapping (in Foo's class of course):

[php]
array(
    'Bar' => array('local' => 'bar_id', 'remote' => 'id'),
    'Quux' => array('local' => 'quux_id', 'remote' => 'Quux.id'),
);

Easy heh ?

As usual, any comments are appreciated, and please note that this code is released under the same license as the ZF itself, the new-bsd license.

Of controller plugins and directory layout

Geoffrey — Sun, 23 Sep 2007 00:55:00 +0200

When anyone on #zftalk ask about where controller plugins should be kept, we usually responds something like have your own library namesapce alongside Zend/ and put it in it like YourNamespace/Controller/Plugin/YourPlugin.php. But what about application specific controllers ? There's a time where you have to write a plugin that relies on the application at such a level that using it elsewhere would make no sense. In that case, where can we store this plugin ? The question arised this morning, and we ended up to the fact that having a controller-level plugin directory would not hurt, after all. So one could have the following directory layout (simplified on purpose):

/application/modules/default
    /controllers
    /library/Plugin
        MyPlugin.php

The drawback is that in order to use autoload you would have to have each modules Plugin dir in the include path, which is a bit of a hassle. Instead, we could have the much more simple folloing layout:

/application
    library/Controller/Plugin
        MyPlugin.php

Which is simpler but does not allow for modules specific plugins. Anyway, the former layout would require a bit more logic in the bootstrap in order to extract every modules path as plugins are registered pre-dispatch.

Hope it helps with directory layout organization :-)

UPDATE

What I've finally decided to do is the following:

/application
    library/App/Controller/Plugin
        MyPlugin.php

So that application specific code gets prefixed with the App_ namespace.