Tag Archives: code

Setup Zend_Rest_Route with multiple modules

Say you have an application and you want entire modules or just a controller to be treated and follow the RESTful ways you can do following in your bootstrap.php:

As you can see the 3th argument of `Zend_Rest_Route` will set “module”, or “module” => “controller”. Quite useful if you have an api module you want to treat as RESTful, or maybe a controller in a specific module used for some ajax stuff.

push and pull for 960 and Compass

So ive been playing with Compass all weekend (and should sleep right now!). I started out trying to figure out the blueprint framework but had to give up. After a lot of work with 960, blueprint just seems weird. So i installed the 960 plugin for compass and started hacking. Though i found that it didnt have the push and pull feature. I hacked together a quick fix for my tiny project and this is what ive got:

Put this in your _base.sass file and you’ll have access to +grid-push and +grid-pull. The attribute is determine the push or pull value and add’s left: (columnwidth * attr) to your class, id or element

I have to say, im not 100% that this works as it should, but give it a go and let me know if im doing it wrong!

Stylesheet abstraction

Chris Eppstein hit me up on twitter telling me about his post on Stylesheet abstraction. Its a great read if you havnt read it already!

On that note i just wanted to agree on tools like Compass are awesome. Ive worked a bunch with LessCSS and also Compass in its early days but never got the hang around it. I was too annoyed with the compiling of css and the way of doing things never compelled me. I still believe that you can write awesome and readable css code without using tools like Compass and LessCSS. Though they make it easier for you, they also add another layer on something very simple. A quick change is never a quick change anymore.

Despite that i still find Compass very compelling and i will sure play with it on my next project! I specially love the utilities and the grid integration with 960.gs and Blueprint If you want to have a look at Compass you should watch the 1 hour long screencast Chris did. Super great stuff! Thanks Chris

Structure your CSS

One of the most annoying things in the world is editing someone else css code. Css in it self is not very structured and doesnt make a hole lot of sense without comments and document structure.

To get this working in our development environment we need a set of rules.

  1. Always use tabs. I prefer 4 spaces using tabs
  2. Use a naming convention that describes what the element does and contain. Not on what page it appears. No more .frontpage-mywidget {}
  3. Split up css in multiple files. One for layout and one for widgets. By multiple files i dont mean 4,5,6 or 7. Keep it simple!
  4. Keep your widths and padding off each other
  5. Use YUI Reset!

To go through some of these rules, let me show you some examples.

1. Use tabs!

Tabs makes css so much more easier to read. Dont write long lines like this:

See what i did there? Even though background: #fff might might make sense background-color is way more describing. Oh yeah, and the tabs. If your scared that your file might end up big and bulky you could always compress it using PHP.

Tabs also makes it easy grouping information. Say you have a widget called login. The frame for .login might not have any styles but the items underneath have. To easy the reading do something like this:

That way you can easily read what belongs to what and also get a sense of the markup structure. Easy right?

2. Naming conventions

One of the hardest things in css is to reuse your classes. Imagine your page might have a widget section on the frontpage but also on a subpage, though the subpage is slightly bigger. Maybe you want all your widgets to follow the same structure, both in markup but also follow some some generic rules.

Take this markup for example:

The naming conventions should be pretty straight forward, and the css pretty much writes it self right? If not keep reading!

The html and css pretty much match exactly and you can read the html from the css, and the css from the html. The great thing about this is that it’ll make perfect sense for new developers to continue where you left off.

3. Split css in files

Removing layout and grid like things from the rest makes it easier to read and also more manageable. This can be done in a numerous ways. Its up to you really but something like layout.css, widgets.css and blocks.css isnt a bad start.

4. Widths and padding dont play nice

Widgets are a dangerous thing and “should” not be merged with classes containing paddings. Its a hard rule to follow but it makes it so much easier doing flexible code. Remember divs are block elements and will fill out the containers width. If a div doesnt have a position, it’ll always be relative to the element above or its container. Though if your element is absolute, it’ll position it self to the first parent element with position:relative defined. When defining absolute as position the browser might position the element relative at first. To “fix” this add top:0px; left:0px; to move it to its absolute position.

5. YUI Reset

Theres a bunch of css resets out there. One might be better than the other but ive found that YUI’s method is quick, clean and easy. It works great and makes html render very much the same way in every browser.