Want to get Lullabot article, videocast, and podcast announcements delivered right to your in-box?
Let us know your email address (we won't share it) and we'll let you know when anything exciting happens.
Glue Code
July 9, 2007
Here at Camp Lulalbot we've been whipping up a series of sites that differ from our normal work: they're meant to be built with no custom code, only contrib modules and UI-driven configuration. Sure, there might be a bug here or there to fix, but the idea is to speed things up dramatically by sticking to 'pure' contrib code.
In a lot of ways, it's dazzlingly cool. We've been able to put together a relatively advanced social site with some great community features in record time. But on the fuzzy edges -- the tweaky little bits of the designs, and a few ideas we thought would be simple -- it's apparent that doing some things WITHOUT custom code is really annoying and convoluted.
Some of this is due to the law of diminishing returns. Making simple, easy-to-use administrative interfaces for the really COMMON tasks pays off nicely for developers. Things like making custom content types, building listing pages, and so on are so common that Drupal's UI-based builders for the tasks have become pretty powerful. The more esoteric the tasks get, though -- the more site-specific -- the harder it is to provide good tools for non-developers. A task that might take 30 minutes and 20 lines of PHP in the hands of a developer could be performed by any site administrator using a configurable UI-based wizard. Building that wizard, though, could easily take hundreds, thousands of lines of code and man-months of development time. Where's the line between 'needs to be automated' and 'seriously, just stick some PHP in...'?
All this is to say that I have newfound sympathy for the non-developers who want to put together complex sites with exacting specifications. You can get 90% of the way there pretty easily, but the final 10% will require compromise, or custom code. Drupal has massively accelerated the process of putting together feature-rich sites for us, but sometimes -- as with LEGO building blocks -- you don't have just the right piece in your bucket of bricks.
Twitter
Mailing list
RSS Feed
Comments
Yes
I recently went to DrupalCamp Seattle and this was one of my big takeaways. Almost everyone who came in with a development question had a very site-specific need that wasn't being met, and no idea how to implement it. Most of these had to do with image/file handling. They could get so tantalizingly close "but for these one or two last things." I'm not sure there is (or even should be) an answer, but it is worth discussion.
After the camp I realized how difficult this makes training. The host went through the relatively standard module dev/theming classes, but every question she had to field was so specific to the user's needs. Sure they wanted to learn how things worked, but to greater or lesser extents most of these people had the basics down already. What they needed to know was how to solve their individual problems. Obviously in the grand scheme of things, its better to teach people to fish, but sometimes people can learn the most by going through the task of solving their problem as well (I think this is especially true with Pro Drupal Development out, since it so handily covers many of the introductory topics for developers.) It is definitely an interesting time in Drupal land right now.
Exactly
You hit the nail on the head for many of us who don't code, or not well enough to trust on a production site. We tend to stay with contributed or core code knowing that someone is looking over our collective shoulders.
Even a very sophisticated module should be able to be reduced to a number of checkboxes and css. Many of us can live with that. It is really a matter of how the developer prefers to document their work. Put it in a document or the Admin UI. Sadly, many developers don't document anywhere.
I hope you will keep us updated on your work.
Appreciate the 90%
As one of those non-developers, I really appreciate the 90% that IS there. Somehow, the concept of "glue" seems to too permanent to me. Maybe virtual velcro (I hope I am not stepping on any copyrights or patents here), to accommodate those "change orders" that Jeff R talks about in the podcasts (appreciate those too!).
Thanks!
Functionality vs design
I guess it's a matter of confidence in our coding talents.
As a (mostly) non-developer I'd be reluctant to write large chunks of code with read/writes to the database and other things that can break the whole site.
On the other hand writing simple block snippets and a couple of if statements in a template file is easy and can't do much harm.
The frontier is probably here. I think designers won't go far beyond the UI, we like to use existing, reliable components so we can focus on what we do best.
It's a bit like product design: engineers build components, a mother board, a speaker, an antenna, and the designers try to make the best use of these parts.
That 90/10 Split is Also Strong Motivation....
You're absolutely right -- Drupal can be infuriating when you can't do something that seems so simple, and when other, seemingly more complicated tasks were a snap.
But the 90% you can do with little or no PHP knowledge is empowering, and pretty addictive. So the challenge of figuring out those last bits, in my view, is what can lead non-developers to learn enough to act as a pseudo-developer -- and who knows, maybe even become a real one eventually. (It seems like quite a few people pick up PHP solely because they want to do more with Drupal.)
I'm not sure I can claim even the "pseudo-" label just yet, but I certainly find myself mucking around with PHP and MYSQL more an more these days.
Also, your post inspired me to something I'd been mulling for a while: For those who haven't even learned their way around Drupal's "out-of-the-box" contrib options, I've pulled together my layman's guide to must-have modules for non-developers.
I hope that's helpful to some -- it'd be nice to give back to the community. And trust me, my PHP snippets at this point are not the kind of help that anyone needs...
-TKS
ready to give up on drupal!!
honestly this is a mess!!
some things are impressive yet some things suck!
I am a programmer with asm/tcp/dhtml/dom etc. knowlege
I have spent 2 weeks reading thru docs and I can't break thru the simplest task of writing anything to mysql and then reading it back using core drupal!!!
is this possible?
Reads and writes
This kind of stuff is actually pretty simple. the db_query() function is a DB-agnostic version of the same mysql_query and pg_query() functios that db-specific PHP packages provide. Using it should do the trick.
Thanks Jeff, I've tried many
Thanks Jeff,
I've tried many ways to use db_query() to create, insert data thru the Drupal framework, it might be writing successfully I don't know,because I can't afterwords read it?
are you suggesting that I create another mysql database and use php to build my data structures?
can it be done using the drupal database?
Post new comment