We need to have vim installed of course.

$ sudo aptitude install vim

Vim doesn’t seem to create the user folder automatically. So we need to create these our self. We’ll start off with a folder for plugins, color schemes and syntax settings.

$ mkdir ~/.vim
$ mkdir ~/.vim/{syntax,colors,plugin}

Most of the time i will be editing .php files. So i want some good syntax support for that. Vim has a nice plugin system. And there does seem to be a syntax file for PHP available. It’s a bit outdated. But will do for now. The only thing to do to enable it is copy it to the plugin directory.

$ mv php.vim ~/.vim/syntax

Now we have a very powerful but basic PHP editor. That’s nice and all. I would like to at least have some sort of a project manager. And there is a plugin for that as well. Download & copy!

$ mv project.vim ~/.vim/plugin

Ok that’s pretty cool. But it still looks like crap. Time for some theme sugar. It actually took me quite some time to find a theme i like. Guess i am picky. The theme / colour scheme i settled for is called wombat. The original file didn’t do much for me. But i found a good 256 colour version.

$ mv wombat256mod.vim ~/.vim/colors

That’s starting to look like a pretty nice setup. Time to make some settings permanent and to enable some other features.

$ vim ~/.vimrc

And add some settings

set rule
set wrapscan
set number
set backspace=start,indent,eol

set t_Co=256
colorscheme wombat256mod

autocmd FileType php set omnifunc=phpcomplete#CompletePHP

In the meantime i found this interesting post on Matthew Weier O’Phinney’s blog about using ctags , VIM and PHP. That looks like interesting stuff. So let’s add it. With ctags it’s possible to scan a source tree. And compile a sort of index file that vim can use for lookups.

$ sudo aptitude install exuberant-ctags
$ mkdir ~/.vim/tags

Creating an index file is a piece of cake. Move to a source directory and issue the following command.

$ cd /some/path
$ ctags-exuberant -R -f ~/.vim/tags/filename -h “.php”
–exclude=”.svn” –totals=yes
–tag-relative=yes –PHP-kinds=+cf
–regex-PHP=’/abstract class ([^ ]*)/\1/c/’
–regex-PHP=’/interface ([^ ]*)/\1/c/’
–regex-PHP=’/(public |static |abstract |protected |private )+function ([^ (]*)/\2/f/’

This will scan the whole directory structure recursively while using the regular expressions to extract useful information from the source files it finds. When done and when the parameter –totals=yes is used the following output is displayed. But probably with different numbers.

2375 files, 466018 lines (14628 kB) scanned in 11.7 seconds (1246 kB/s)
199296 tags added to tag file
199296 tags sorted in 0.00 seconds

Time to enable tags. I want to use multiple files. Some standard files for common frameworks / libraries. And a tag file per project.

$ vim ~/.vimrc
set tags=tags;~/.vim/tags/filename

So let’s start vim and have a look at what we have so far. The first thing we do when vim has started is launch the :Project plugin.

$ vim
:Project

The project plugin took some time to get used to. But it’s a very convenient plugin. And easy to get the hang of. It’s possible to create the project settings by hand. But the plugin comes with a build in tool for this. While in :Project mode and hitting \C will make it easy to create new projects.

$ vim
:Project
\C

This will guide you through the process with a few short and simple questions.

Enter the Name of the Entry: [ project name ]
Enter the Absolute Directory to Load: [ absolute path ]
Enter the CD parameter: [ path to move into ]
Enter the File Filter: [ file filter : *.php ]

When that’s done the screen will be in edit mode inside the .vimproject file. Displaying something like this.

Project name=/path/to/project CD=/path/to/project filter=”*.php” {
filename.ext
folder———————————————————-
}

It’s possible to alter the project setup here. Like adding more files. Or even adding files from other locations outside of the project.

Project name=/path/to/project CD=/path/to/project filter=”*.php” {
filename.ext
folder———————————————————-

External=/some/other/path CD=/some/other/path filter=”*.php” {
filename.ext
}
}

When done editing. Just do like normally in vim.

:w

Pretty cool we have a project browser on the left. That is easy to navigate with the arrow keys. And a work canvas on the right.

Time to test the ctags created index files. Place the cursor at the beginning of a string that you want to lookup. And hit CTRL + ] and CTRL + T to get back. Another cool way to open the source file is by using horizontal split windows by using CTRL + W ].

Testing auto-complete is just as easy. Type some php core function name partly str_ and hit CTRL + x and CTRL + o. This will display the following scrollable drop down..

That’s about it. I had good fun exploring all the features and possibilities. And have only scratched the surface. One more thing i found on Matthew’s blog was a way to test and run PHP script from vim. Awesome stuff. You can read about it here. Although i like vim. I don’t think i will be leaving ZS any time soon.

So today i took a bit of time to think about a good structure for our new SVN repository here at the office. After a bit of browsing the web. Looking at other proposals. And looking around our old SVN repository. I came up with a new structure.

Our SVN repository will start off with three directories.

– Development
– Design
– ??

The Development directory is what i will be talking about. I can’t talk for the designers. Because.. well i’m not one of them. Although i did a lot of design work in the past. The ?? directory is for another part of our department. So let’s see what i came up with.

Inside the Development directory we start of with two directories.

– Projects
– Library

Projects:
This directory will contain all projects. With projects i mean web applications / sites. All these projects will adhere to a basic structure. Which i will talk about a bit later. Besides the same basic structure. Every projects has the trunk, tags and branches sub directories. If a project contains “sub” projects. The trunk, tags and branches will shift one level deeper in the tree. Below is a small example.

– Project_1
—- trunk
—- tags
—- branches
– Project_2
—- www
—— trunk
—— tags
—— branches
—- intranet
—— trunk
—— tags
—— branches

Library:
The library directory will contain all shared libraries. This can be third party libraries or internally developed libraries that will be used in multiple applications. Below is a small example. I’m not sure about the trunk, tags, branches directories yet. For the internally developed libraries we will implement this structure. For the third party libraries we won’t. I think :)

– Zend
– DB
—- trunk
—- tags
—- branches

Now this will cover most of the project parts. What’s left now is defining a basic structure for the projects that will ive inside the repository and on the web servers. For a basic structure i’m inspired by the layout of an Zend Framework MVC style project. Why? i already work with this structure for a while now. outside and inside the Zend Framework projects. It separates the code from the views / templates. It makes sure the code is outside the web root. And it just looks clean.

So for our projects i came up with this structure.

The structure really consists of three parts. The first is “public”. This directory contains all data that should be globally accessible. We can think about images, stylesheetes, javascript libraries, etc.

– public
—- images
—- css
—- scripts
—- index.*

The application directory contains all the real code and views / templates. All views / templates will be stored in the views directory. All project specific code will be placed in the library directory. And if the project is MVC based. It will use the controllers directory to store the application controllers.

– application
—- controllers
—- library
—- views

The final part of the structure is a collection of directories that can but are not always used in a project.

The logs directory can be handy for logging data of the application. But can also be used to store php error logs or maybe even Apache logs. The cache directory is there to store cached files. The structure inside this directory will depend on the cache mechanism used in the project. The files directory contains files that are somehow linked to the project but have no place in any other directories. Some test scripts or tools can be placed there. And last but not least the docs directory. Which will contain all project documentation.

– logs
– cache
– files
– docs

I wanted to post this yesterday. But i just couldn’t find any time for it. Yesterday i showed the initial proposal to the rest of the team. But we didn’t decide yet. What the final structure will be.