Josh Benner's Blog

Make Views More Flexible/Maintainable

Josh — Sat, 24 May 2008 09:53:42 -0600

Any Drupal developer worth his salt at least knows of the Views module. The shear usefulness and time-saving nature of views has earned the module a place in every Drupal site I've developed. However, because views are stored in the database and their presentation is controlled by the views module itself, managing views between staging/live sites, handling updates, and tracking revisions become difficult issues when dealing with Views. On the other hand, source code is easily managed between copies of a site, updates are a breeze, and revisions are natural -- all of this with revision control, such as Subversion. Also, what if you want to implement complicated access rules for your view?

Views documentation has a section on how to programmatically build and render views. This is great, but building a view programmatically takes a lot more time than using the Views UI because you're constantly trying to figure out the table/field names used by the various modules that provide views integration, let alone filter, field, and argument settings. If your development cycle is anything like mine, taking more time on something is not always a luxury you can afford.

Views module also provides an interesting Import/Export feature that allows you to copy/paste a view definition between sites. This helps with moving a view between two copies of a site and even helps a little dealing with updates. If you're diligent, this could be used to deal with revision control as well, but it's still a little clunky if you're maintaining and building sites all the time.

In my opinion, the sweet spot when dealing with views is combining views exports with embedding views in your own PHP code.

Every Drupal site I've developed as ended up with a "custom" or "glue_code" module that does various minor modifications to the site, such as hook_form_alter, hook_nodeapi, hook_menu, etc. I've also started to use this type of module to render and provide default views using the following process:

First, during development of your site, go ahead and design the view using the Views UI as you normally would. We'll call this view example_view.
Once you have the view's page display the way you like it, keep the page display enabled, but clear the URL so that the view page isn't really accessible anywhere on your site.
Now, export the view and copy the large export array that is provided.
Implement hook_views_default_views() in your custom module. Simply paste the exported views array into this function. Be sure your code makes sense and returns something according to the hook spec.
Delete the view from your site, because your custom module will be providing it now.
In your custom module, add a new hook_menu item that points to a callback that will provide the view. For the purpose of this example, our callback is called 'custom_view_page'.

The custom_view_page() function will then look something like this:

function custom_view_page() {
$view = views_get_view('example_view');
return views_build_view('embed', $view);
}

That will retrieve the view (the default one provided by your implementation of hook_views_default_views OR the overridden version if you've defined a view in the UI by the same name), then render it for output. If you need to send arguments to the view, pass them as elements of an array in the third parameter sent to views_build_view().

Benefits:

View definition is no longer in the database.
Updates are performed by updating code base. Simply build updated version of view on dev/staging site, export, and update the hook_views_default_views() implementation.
Revisions of changes to view are kept in source control.
All benefits and flexibility of views is maintained.
Finer control over things like access to the URL that provides the view.
Possible performance gains (untested).

Ecto and Drupal

Josh — Mon, 12 May 2008 21:07:09 -0600

A few weeks ago I read a brief but interesting article by Jeff Whatcott on Getting Ecto Set Up with Drupal. I had heard of Ecto in passing but had never really looked into using it. With all the hubbub around WYSIWYG tools for Drupal and the like recently, I wondered if a good desktop application would be a viable solution, so I figured I'd give Ecto a try for myself.

I was initially very impressed with the relatively simple interface sported by Ecto. After quickly configuring the blog_api module on Drupal and just a few clicks in Ecto I had connected to my Drupal blog and was presented with a list of the blog posts already published. I explored the various configurations and was pleased to find a lot of configuration options -- this isn't just a handy app, Adriaan Tijsseling has done a fine job putting together a fully-featured application workspace.

I decided that I owed Ecto at least a couple blog posts to see if I could use it effectively on my Drupal installation found at jbenner.net. I set about writing my first post with Ecto, and was very comfortable at first, typing away and easily setting basic font styles, adding links, and breaking paragraphs. I was a little confused by the interface to select "Categories" and "Tags" -- as I was entirely sure how they translated into my Drupal environment.

I published the post, then went to my site to check it out. For the most part, things looked okay... there were a few minor formatting things here and there that most likely resulted from oversights on my part while preparing the post. The problems came in when I started inspecting the post in more detail. First, Ecto didn't seem to set my topic tags at all -- for future reference, ignore Ecto's tags, and just use Categories.

Also, I use the pathauto module to automate Drupal's path aliases -- but posting using Drupal's blog_api seems to go right around pathauto. From a Drupal developer's perspective, this will probably make some sense, as I imagine that pathauto does its magic with a combination of hook_form_alter() and hook_nodeapi(). Does blog_api skip various hooks? This might be worth more investigation.

Add to this Drupal's lack of proper time zone handling and you get a rather confusing set of configurations between Drupal and Ecto to get both Ecto and Drupal to show the same (and correct) time. I eventually got a pair of settings that seemed to almost work properly, but the journey was ripe with confusion and lacked a satisfying end. In fairness, I think this may be a shortcoming of Drupal, though I'm not entirely sure in this instance.

Ecto has an option to set the input format to use when it sends the post to Drupal; however, it did not seem to set this correctly in every case. I don't know what was causing the difference in behavior in different instances, but this is an issue worthy of note.

As a note -- don't touch Ecto's summary feature if you're using it to post to Drupal. For some reason, it sends Ecto into a spiral of arguing with Drupal over the contents of your post, and seems to always end up adding what it wants your summary to be at the beginning of your post with broken HTML. You're better either setting your break tag manually in the HTML or creating a custom HTML tag in Ecto and inserting it that way.

Overall, Ecto did a fair job of posting. However, between skipping pathauto and the time zone issues, I can't see myself using Ecto regularly, as I'd find myself in Drupal's node form fixing things up anyway. More importantly, Ecto doesn't really simplify the process of posting blog entries in general, though it does offer some nice tools for performing more advanced blog actions, such as integrating images, or Amazon and Flickr resources. If anything, I could see myself using Ecto to write drafts and performing cleanup and publishing in the web interface. This might especially be handy if I want to start a post while offline.

I don't see myself encouraging any clients to use Ecto with Drupal at this point. I want to emphasize, however, that this isn't necessarily because of problems with Ecto as much as some problems between Ecto and Drupal.

My OS X Toolkit

Josh — Wed, 16 Apr 2008 21:25:09 -0600

After the first day of having the new Mac and playing with iChat, it was time to hunker down and start accomplishing things with the Mac. In the last few years one of the biggest reasons I've been reluctant to get a Mac has been a sense (whether justified or not) that the software selection wouldn't be sufficient for my wants, needs, and tastes. Part of my recent decision to get the Mac was the general feeling that this was no longer the case. I've found this to be true.

I spend a lot of time on my computers. Most of that time is spent using or writing web pages and web applications (and the occasional video game). Web development isn't what it used to be, and tackling everything requires a lot of tools. I'll summarize my needs and the tools that I've settled on using to meet them.

SSH Terminal
Windows: puTTY
OS X: iTerm
Most of the stuff I found on the web about doing SSH in OS X said "just use the terminal!" While I like the OS X terminal, I was hoping to find something to help me manage sessions and generally make all the SSH connections I juggle in a day a little easier to use. Enter iTerm -- it does just enough using its 'bookmarks' and connection and keyboard profiles to make managing multiple console or SSH sessions graceful, and its tabbed interface is another step in keeping my workspace navigable. Oh, and it's free.

Text Editor
Windows: Notepad++
OS X: TextWrangler
OS X comes with a nice little text editor aptly named "TextEdit" that is pretty good, but I like text editors that go the extra mile. I like to search and replace with advanced regular expressions. I like a text editor that implements a good system to manage a bunch of open text files. I like a text editor to do basic syntax highlighting in the event I don't open a file in my IDE. TextWrangler does all of this and so much more. And its free!

Web Browser
Windows: Firefox
OS X: Safari and Firefox
I love Firefox, and it was the very first thing I downloaded on the new Mac. However, I felt I owed it to myself to give Safari a fair shake, especially since I've been impressed with the betas (and recent release) of Safari 3 on windows. Safari on OS X is fast, clean, and nice to use. If Safari had the plugin base of Firefox, rendered a few more sites better, and had some minor usability tweaks... okay and a bunch of other things, I'd use it as my primary browser all the time. For now, I enjoy using both of the browsers side by side.

Development Environment (IDE)
Windows: Eclipse
OS X: Eclipse
I have been very happy with Eclipse on Windows (and Linux) for a few years now, and it just keeps getting better. When I started working on the Mac, I wanted to use whatever was widely used by the Mac development community. A lot of web developers I know who use Mac as their primary OS use TextMate. While I liked TextMate (a lot), between the TextMate price tag ($64), the effort of learning a totally different interface, and the fact that Eclipse works great on OS X... I stuck with what I knew in this department. Expect more on this later.

Local Web Application Stack
Windows: XAMPP
OS X: MAMP
When I develop a web application I almost always work locally and migrate the changes to the live server. This development pattern has so many advantages that I can't believe there are web developers that still don't use it. A few years ago the way to do this was downloading and installing (sometimes compiling) the various components of the stack (usually Apache, MySQL, and PHP). More recently groups like apachefriends have put in great effort to package the components in easy-to-use, point-and-click packages. XAMPP is a great packages for Windows and is also available for OS X. I tried XAMPP for OS X, but when I tried to configure it with things like vhost aliasing and such, it kept resulting in errors and odd behavior. I then tried the free version of MAMP, which I found to be much easier to configure.

A Voyage Home: My Return to Mac OS

Josh — Sun, 13 Apr 2008 00:10:09 -0600

People often ask me how or when I started working with computers, programming, etc. My answers usually hark back to my childhood and my first ventures with my parents' Macintosh Plus, then our family Performa, and my Powerbooks 180c and 540c. Basically, all of my earlier computer encounters were on a Mac, from learning to type to learning my first programming language to discovering the internet for the first time.
Sometime during the late 90s I became frustrated and angry with working in a Mac world and I "converted" to my first Windows machine, vowing to never look back. Since that day I've been working primarily in Windows and Linux, only touching a Macintosh when absolutely necessary... that is, until this last week.
When my new 15" Mac Pro arrived and I opened it and started it up, I was consistently impressed with how easy it was to use, and how well it "just worked." The experience has been a far cry from the agonizing memories I have of Mac OS 8 & 9. I spent some time playing with the software that Leopard comes with, such as iChat, iCal, etc. I have to say... iChat is effective, Photobooth is a blast, and syncing the iPhone with the Mac is an order of magnitude better than with my Windows box.
I've spent a respectable amount of time making the Mac work the way that I like, such as managing hotkeys, setting up my command line environment, and trying to find a software to meet my many needs. The process has been fun and I've been very pleased to find that the solutions available for Mac are closely related to (and sometimes better than) the Windows software that I regularly use (more posts on that later?).
All of this to say that I'm not only happy with the Mac, but I've been overwhelmingly surprised at how much I'm enjoying the experience. I won't be getting rid of my windows or linux boxes any time soon, but the Mac has quickly secured its place in my toolkit.

Adventures with VersionOne

Josh — Mon, 07 Apr 2008 15:44:19 -0600

A few months ago the primary project to which I'm assigned espoused an Agile/XP approach for development... well, a heavily modified Agile/XP approach as there is only one developer (me) working on features/tasks/etc that come from a team of people, funneled through a project manager of sorts before they get to me. Because of the unique relationship we've enjoyed with the client, managing the project has been an interesting challenge since client users are involved closely with the project and are sometimes responsible for tasks such as testing.

We've moved between a few task tracking/project management systems in the process, trying to find software that fit our needs, the latest of which is VersionOne. The client actually came across VersionOne, which I'd only heard of in passing before that point, and asked if it would be a viable system to use during development. After a quick glance by several of our team members, we agreed that the system looked pretty good and was unique in that it was designed with Agile in mind so it supported the Agile/XP workflow in a manner than other ticketing systems didn't. So, over the course of a couple days we migrated to VersionOne and started using it.

The first thing that impressed me about VersionOne (aside from its nice, Web 2.0 shiny look) was how you can customize every view you have access to. You can specify which columns to show, and even which you would like to be able to edit inline (great feature!). This allows for a customized experienced and access to information the way you want it.

It wasn't long before we started running into the challenge of figuring out how to pass information back and forth. VersionOne has nice "Notes" that can be attached to any object (story/defect/issue/request/task/etc); however, as far as I've been able to tell, the overly-complicated but barely useful subscriptions/notifications feature does not allow emails to be sent to let me know when there's been a new note on an object. In fact, the notification system won't send emails at all -- the only option you have is a personalized RSS feed that pushes nearly useless notifications about the various objects (not including when there is a new note).

In pursuit of a workable setup, I discovered that VersionOne has an Eclipse plug-in. I rejoiced. That is, until I installed and used it. The plug-in is horribly buggy and exposes an abhorrently limited set of abilities to the user in the Eclipse environment. All in all, the plugin should be abandoned and they should put some honest time into writing a good Mylyn connector.

Lacking an email option wouldn't even be so bad if the notification system's personalized feed provided useful information about the objects for which it's updating feed items. After a couple days of tinkering with notifications, I've all but stopped paying attention to the notification feed and have been forced to rely on a combination of clever custom statuses, a custom 'status note' text field, and pure memory to determine if an object has been updated in a manner that needs more attention from me.

Overall, however, I've been really pleased with the way VersionOne works and its slick interface. I'm holding out hope that with time I'll either get used to how VersionOne wants me to communicate or uncover a feature I'm not yet aware of that will help bring important information to my attention.

Don't Use It, You Lose It

Josh — Mon, 31 Mar 2008 21:44:27 -0600

A friend of mine has been using CakePHP to solve some problems where he works lately, and has been asking me for some help here and there. I always love to help as much as I can, but lately I've found my advice when it comes to CakePHP to be less helpful than it was in the past.

Now, ask me about Drupal stuff and I can answer most questions that you could come up with (I think?), but that's because I use Drupal day-in and day-out, for both my job and the hobby stuff I do on the side. The side effect is that I find my skills using other technologies suffer since I don't flex those muscles as much. I even worry about some basic coding skills -- since Drupal manages so much of the application execution process, I don't have to worry about a lot of the more technical (cool) stuff.

Don't get me wrong -- I love Drupal. I think it's the best CMS out there. I just wish I had more opportunity, time, and possibly motivation to use some of the other technologies I enjoy... like CakePHP.

Technical Debt -- The Best Laid Plans...

Josh — Fri, 28 Mar 2008 15:46:17 -0600

Over the last couple months I've been hearing the term "Technical Debt" get thrown around frequently, describing the effect that results when decisions are made in a project or process that cause problems down the line.

As any good developer will tell you, there are usually more than one way to solve the problem. Once you've narrowed down your options to a few viable courses of action, it's usually the fastest or cheapest that gets chosen. I'm not here to say this is an incorrect way to choose between good options, but I'd say that when we're planning the development of a project, or even just a feature, we ought to also say to ourselves, "Which approach will leave us with the least technical debt?"

The problem is that this isn't an easy question to answer, because we don't always know what new technology, approach, service, or totally different alternative is coming down the road. So what seems like the best idea today may be what we lose sleep over a year from now. What are our options, then?

After jumbling it around in my head and thinking through some of the real-life examples I encounter in my every day work, I think the best answer is to consider which is the most flexible approach. Which solution ties us down the least? Which method is the easiest to rip out, expand, convert, or replace at a later date? What does approach A prohibit that approach B does not? What technologies or methodologies are we committing to by choosing one option over another?

I don't think that I'd go so far as to assert that the most flexible option is always the best, but rather I'd stress that giving flexibility heavy consideration in the decision process is warranted... because you may be paying out the time and/or money later to the Technical Debt accrued by your decisions.

Introducing jbenner.net!

Josh — Thu, 27 Mar 2008 21:15:10 -0600

I felt like having technical blog entries next to personal picture galleries and such a little out of place. That plus the fact that http://bennerweb.com was the first Drupal site I ever set up... I felt I needed to move to some new digs... with every intention of posting more regularly with technical and non-technical articles alike.

I considered giving Drupal 6 a whirl -- but after working on it a little, the hard truth was that I still have more freedom and flexibility with the shear number of modules available for Drupal 5. I'm excited for Drupal 6 coming of age through the summer of 2008... but it's still just not quite there.

I had high hopes of putting in some good Drupal community time over the last month after Drupalcon Boston 2008, but alas... clients still come first.

Stay tuned!

Analysis of Drupal as a Framework

Josh — Sat, 17 Nov 2007 22:20:21 -0700

I recently presented at an event where several web application frameworks were discussed, including Drupal. Around that time I was also working on several projects written as Drupal modules at a level that I had not done before. These series of events caused me to take a step back and consider Drupal's merit as a web application framework.

I've often fought with myself in my head about whether a large web application would be best developed from scratch, based on a loose framework (such as CodeIgniter or CakePHP), or based on a large, existing platform such as a CMS. Typically I would have said that if you're writing a relatively complex application, that it might be best to use a loose framework for pure time saving and best practice adherence.

However, I feel that my opinion may be shifting. Many web application share basic components: authentication, authorization, URL routing, user management, etc. The features that typical web applications share read almost as a feature list for a CMS. What Drupal manages to do is not only implement those typical web application features (well), but also expose a considerable, well-thought-out set of APIs that allow programmers to take full advantage of Drupal's core features and wield them for their own purposes.

Node API

One of my favorite subset of Drupal's features is the node api. This system allows the programmer to create modular content types for which Drupal will control all aspects of CRUD, requiring the programmer to write only the code which will dictate that content's behavior that is different than the norm, such as the layout of a specialized form or storing extra data in the database.

Form API

The Form API is another example of one of those systems that I've found myself often imagining programming for myself. I've often though, "There has to be a way to write a system that will make doing forms and the related HTML not suck so much." The Drupal Form API is that system that I've desired for so long. Creating a form is as simple as populating a rather simple array, describing each field's properties in short form.

Conclusion

I would encourage anyone looking for a framework, nay, a platform upon which to build their web application to carefully consider Drupal. I'd venture to say that just about anything you'd want to accomplish is either already implemented or is (relatively) easily accomplished using Drupal's API and core modules, let alone the community-contributed content.

Write a Reasonably Complex Application with CakePHP/Drake/Drupal?

Josh — Tue, 24 Jul 2007 16:07:40 -0600

This post is in reply to a comment on a previous article that I thought contained some good questions:

Hi Josh,

Saw your post on the cakePHP list regarding Drake, here http://groups.google.com/group/cake-php/browse_thread/thread/4d0ad8b73a5... .

I'm hoping you won't mind answering a couple of questions.

In particular, I am concerned with the performance hit of running a framework within a framework, and all the associated redundancies. Was performance something you looked at in any detail?

How much harder is it to work with Drupal's API from within cake than it is to write a native drupal module?

Did you feel the benefits of using cake overcame the increased complexity of having to bridge using drake?

In your opinion, if one wanted to develop a (reasonably complex) module for drupal, would you recommend writing a native drupal module, or writing a cake app and bridging it with Drupal?

Thanks very much.

Hopefully you will be kind enough to reply.

Sorry for taking some time to get back to you! Been busy!!

Yes, I looked at performance issues with Cake in Drupal (Framework in a Framework as you said). For our application, we're weren't looking at really high traffic. The initial box I had for the project was an old dual P-III system running RHEL5. It performed pretty well with some unexplained pauses here and there (may have been hardware related).

We recently migrated the site to a Virtual Machine hosted on a VMWare ESX server -- the performance is excellent! Drupal itself is very snappy and the Cake applications are very responsive. All page loads are under 3 seconds (my target), with the exception being pages with a LOT of data.

You can work with Drupal's API perfectly fine as Cake is executed in the same space as Drupal. We use this fact in some of our small apps that need to know what user they're dealing with, so Cake just pulls data out of the $USER global from Drupal.

The benefits of using cake definitely outweighed the complexity increase. In fact, the complexity increase was pretty negligible as I no longer had to do much consideration of authentication and authorization against our systems (LDAP), as Drupal takes care of that for me. Also, it was easy to integrate the Cake applications with Drupal styles and have a very consistent look, which took care of a lot of the normal UI considerations we were having with other custom apps (ie: things are too ugly :) ).

I see a Drupal Module and a Cake app running inside Drupal as two different beasts. If I wanted to add functionality to Drupal, like add a new content type with custom handling, I would use a module. If I wanted to write an application that I wanted to "live" within a Drupal site, I would use Drake/CakePHP.

Now, your question was mostly about a reasonably complex application. My assumption is that a reasonably complex application's benefit to existing inside Drupal would come primarily from relying on Drupal's many charms, including authentication/authorization handling via user/role-based security, content type management, views (I love views!), exposing data in blocks, etc. Saying this, my initial answer would be to write it as a Drupal Module, because I would likely want my data to be visible to Drupal as a content type to open a world of powerful managing of the data, and CakePHP models will want to talk to the database directly. While this isn't an insurmountable problem, I'd think at first that this alone would be enough to dissuade me.

You could override AppModel and teach it to talk to Drupal's database layer, though (which might actually be a VERY interesting experiment with Drake). Or, if you weren't worried about your data being visible to other Drupal modules, this wouldn't be a consideration. In our applications, we've (so far) not been worried about exposing our data to Drupal (probably quite the opposite, both for security reasons and based on the fact that CakePHP talks with a completely different database server than Drupal), but I can foresee the day that we might want to.

Could you write an effective, reasonably complex application with CakePHP in Drupal via Drake? Absolutely. But you might have to invest some time on integration between the frameworks if that's a concern of yours. All in all, that's a question best answered in your context, not broadly.