Thursday, December 10th, 2009
I get asked a lot how to go about adding certain CSS files to only certain pages of a Drupal project, rather than every page. This is commonly desired when you are using a drastically different front page in comparison to your drill pages. To achieve this you will want to use the drupal_add_css() function provided by the Drupal API.
It’s very basic in functionality:
drupal_add_css(path_to_theme() . '/layout-fixed.css', 'theme', 'all');
Given a path to a CSS file, it will load it where ever the function is called. The second param specifies whether you are theming a “theme” or a “module” with it, and the third param reffers to the “media” attribute of the <link> tag.
I’ve seen many coders drop this call right into the page or node template they are theming. That is really less than desired, as it tightly links a css file to template file. Say you wanted to use this css file 5 times, you would have to add it to 5 files. That duplication would make it time-consuming to change if you had to alter the name of the file, for example (and that is provided you can remember where you put every call to drupal_add_css()).
A cleaner approach is to put it’s call in your template.php and use some logic to control when to use it. Something like:
drupal_add_css(path_to_theme() . '/crazy-style.css', 'theme', 'all');
Doing this will ensure that all of your dynamically added CSS’s files live in one spot, making it super easy to add or extend to.
To remove an existing CSS file per page, try something like:
$arrCSS = drupal_add_css();
$vars['styles'] = drupal_get_css($css);
Tags: drupal, php
Posted in Code | 13 Comments »
Thursday, April 23rd, 2009
Well, you’d all be lying if you said you didn’t see it coming. I gnaw your ear off in my last post about Doctrine, and how necessary Object-Oriented Design is in web application development, and how I haven’t found that “perfect framework” for me yet. Well, Symfony is definitely on it’s way to being my new framework of choice.
The reasons are obvious:
- MVC Architecture
- Doctrine Powered
- Intuitive and Powerful
- Awesome Documentation and Community Support
Now, I’d be lying if I said that there wasn’t a learning curve. For those of you already cool with MVC systems, then you’re only real task is learning how Symfony divides projects into applications and applications into modules, then it’s just a matter of picking up helpers and useful configurations, and your off. For those who are new to MVC architectures, I would strongly suggest reading up on it first. This is not so much necessary for Symfony, but a good idea in general.
I remember hearing about Rails, and how awesome it is because it’s very powerful and it utilizes cutting edge, sophisticated patterns and systems. While this is wonderful, if you aren’t keen to these things (MVC, Active Record, Database Abstraction Layers, and for PHPers… Ruby), then you are going to get hit with a lot and probably wind up saying “Rails is too confusing”, like I did. But then, with about a good year’s worth of studying in Computer Science and Software Engineer (if only cool Frank could hear me now), I’ve learned of such technologies independently, became comfortable with the concepts, and even implemented these assets in my own projects.
That is the whole point of a framework, after all: to speed up your development. Symfony is doing that for me in a big way, but thanks in part to my past years of software engineering research. I say it all the time, “Programming is organic, regurgitating isn’t”. I found a great framework that works for me, but who knows, maybe it will work for you too.
I’d like to thank gnat42 from #doctrine, you we’re right as always … and you’re allowed to speak now.
Tags: framewok, php, symfony
Posted in Lecture | No Comments »
Monday, April 13th, 2009
If you aren’t already hip to the idea of Active Record, it is the concept of tightly coupling records in a database to an object in whatever language you are working with. This allows you to conceptualize and produce your application in a very similar manor. For example, when you want to make a Blog, you think about A Blog, Comments, Categories, and Tags (to name a few). Object Oriented Design teaches us to think of these as object, requiring you to give them attributes and methods, while UML takes it a step further and defines a system for engineering the software with OOD – linking the objects together to form cohesive functionalities.
Since beginning my masters in Computer Science two years ago, I’ve been on a constant quest for a framework that best suites my needs: fast production, systematic, object oriented, and scalable. Some front-runners may scream “Rails!”, which I tried – but lost interest, mainly because I spent more time trying to play by DHH’s rules then actually developing. (Let me be very clear, I am not knocking Rails or DDH, the framework is brilliant and the community and support is booming, but it just wasn’t for me … maybe in the future.) So I searched for PHP frameworks: CakePHP, Zend, and Symfony were all overkill for me, a lot of bloat that I didn’t need (once again, not “unnecessary”, just “I didn’t need” … the aformentioned PHP framework are also awesome and I applaud them all.) It wasn’t long until I realized that I am only going to be happy if I make my own, and so I did.
Now, any developer worth his salt has an arsenal of code that he reuses, that’s a given. I’m no different: I’ve developed a library specifically suited for my needs consisting of mainly classes, common and layout functions, and random configurations. One key feature that they all rely on is my MySQL and DB class. Together, they act as a sort of abstraction layer to a database. For example, if I did
it would loop through the data, clean it as needed, create and INSERT statement, and return me the results. It worked okay, but it wasn’t crazy flexible. Joins were nearly impossible, so I had to flank my own system by writing straight SQL statements. That was okay, though, because my queries we’re normally very straight forward due to the domains of the projects I’ve worked on. That was, however, until further studying into software engineering opened my eyes to an ugly issue that I find in my code, and in many others.
The issue is as follows: OOD says an object is to be fine-tuned so that it can handle itself the best that it can, it doesn’t know anything about any other object, unless you tell it to. If you need more access, you need more objects. Relational databases, on the other hand, want you to fine-tune your queries so that one statement can grab you all the info you need. So to recap, OOD wants multiple accesses to objects of limited information, and RDBs want a single access to an object of unlimited information. Two necessary components of your app with two differing ideologies.
With a little thought, it becomes apartent that while multiple hits to he DB is really bad, breaking OOD patterns is just wrong. So while researching how to develop an Object Relational Mapper to keep your code OO while keeping effecient DB access in mind, the good folks in #php kept referring me to Doctrine.
Doctrine is an ORM built on top of a database abstraction layer. After extremely thourough investingation, it proves to be an invaluable resource neccesary for any OOD trying to build the most effecient application possible. Doctrine comes complete with a powerful active record class system with an eligent, fully documented API, a database scheme manager, a suite of command-line utilities for various functionalities such as auto-generating models and database tables, a built in fixture system for auto-populating test data, integration for the development of custom test suites, and yes … much more.
Now while these features alone are enough to sell even the most skeptical buyer, what sold me was it’s extremely small footprint and seamless integration with my custom framework. Truth be told, Doctrine took about 20 minutes of reading over the guides to get comfortable with, about 10 minutes to integrate with my existing framework, and now saves hours of code writing. Utilizing PHP5’s object daisy chaining, you can link Doctrine’s lightweight record methods to do in one line what previously took close to 100.
$user = Doctrine::getTable("user")->findByEmail("firstname.lastname@example.org")->toArray();
It doesn’t get much easier than that. Backed by not only a very intuitive API, a well versed documentation, and #doctrine, one of the most helpful and curtious IRC’s I’ve ever worked with. With the development of version 2 in the works, Doctrine is on their way from a being a 3 year old ORM mapper, to becoming an absolute nessecity for any web application powered by PHP.
Tags: doctrine, ood, php
Posted in Lecture | No Comments »