Actually the reason that things are separated is the MVC design pattern. This call for separation between the model, view and controller (The data, how it’s displayed, and how its manipulated). You could toss everything together, but it would be really painful to maintain. What amounts to a minor inconvenience of defining your form in one place, and theming it in another, makes for far more readable, and maintainable code.

The importance of this and similar things should not be underestimated. What if you disappear? Will the project be able to continue? Or better yet, what if your organization grows? Will someone be able to join the project and get working quickly? You can’t hire an expert in your custom framework. Will it take six months of _your_ time for you to train a new hire on your custom framework that doesn’t have a drupal.org to learn from?

P.S. Your name fields appear on two lines in my browser.

By definition there should not be any real logic in a theme function. Theme functions add html tags to pre-constructed data, any logic should happen earlier in the flow. Thus the only real opportunity for a security flaw would be a missing check_plain() on a title for example. And these should be becoming all but extinct in major modules due to the new Drupal security scanner project.

I have far less confidence in the security of my custom code than I do in Drupal or the major contributed modules since more eyes see the code, and more security tools are used to audit it.

I see a custom framework having the same issue, only worse.

But the benefits to using Drupal are a bit hidden until you hit a development wall. As mentioned in the last post, is your security up to snuff on your forms. When you want to add a combat spam, can you drop in the Mollom or captcha modules for instant success. Are all your user permission and controls in place for your expanding user base, with profile fields and OpenID ready a the flick of a switch.

Once you go down the custom API, home spun framework, there is no coming back. The hundreds of devs who are creating new modules and improving current modules are useless to you, and you to them.

I have been working on custom frameworks and Drupal now for years. It is true that I have to jump some building to make Drupal do what I want at times, but when I have a complex one-to-many user permission problem and instantly is solved by plugging in the nodeaccess module, I thank myself again and again that I using Drupal.

It has to be cached for the current request, not just generally in the database. If it was just generally cached in the database, that would still involve one db query per node, which is exactly what we’re talking about here.

I don’t want to use another module which does stuff in nodeapi. I simply want “SELECT * FROM blah WHERE blah LIMIT blah” and that’s it. node_load() does not fit my purpose where I’m showing multiple nodes on one page in a table.

Forms are one area where I really loved Drupal. FAPI comes with a lot of built in security. I want to keep that security, whilst having better control over ad-hoc changes to the HTML layout (not everything can be done in CSS, or at least in the most appropriate and clean way). Yes, Drupal enables me to have complete control, but in a really obscure and abstract way which is very time consuming to deal with for every custom form you have.

Please note that node_load() fetches a cached result if it’s available, so you’re not sending 100 selects to display simple information. It’s getting the information straight out of the cache. Other modules can hook into hook_nodeapi to alter information and, as you say, do access control for instance. By doing the selects straight on the database, you’re bypassing those. This might seem like a good idea now, but if you install other modules later on, this might give you some headaches.

It’s by doing these things manually (selecting node information straight from the db, writing your own forms, …) that you’re bypassing Drupal and that you’re missing out on its strength. It takes a while to learn “the Drupal way” but as yaph mentions, once you know how the handle them, you control very powerful instruments. Once you control these tools you’ll noticate that Drupal doesn’t have a lot of ‘baggage’ but that it allows you to write custom code so much easier and more flexibel.

@Pasqualle:

the super-basic FAPI is super super basic atm and definitely not ready to release on drupal.org. still need a lot more thought but for the job it was required for made things really nice and easy.

Drupal is absolutely different to any other framework, you need to learn it. But when you know how it is working and why it is working that way, you don’t want to use anything else.

I used to think this exact same thing, and still do to some extent. But I’m turning back to my own framework option. Not an all-purpose framework to be used on any new sites I do, but one specific for one particular framework. As an all-purpose swiss army knife Drupal does as well as it could, I don’t want to reinvent that wheel.

I see one big problem with your development practices: you do not work with the community. You try to create everything on your own. That’s not working. Drupal development is faster than anything you can accomplish, you will be left behind.

Don’t completely agree with this. I’ve contributed modules on drupal before (nice_menus, tasklist, and started the idea of hook_watchdog in core). I’ve spent money on Drupal consultants. I’ve helped and asked for help in IRC. I go to Drupal meetups. In short, I’ve really tried.

@Ronald

Where Drupal shines, I think, is as a tool for a web agency that every month needs to deal with very different kinds of websites and can quickly put them together using Drupal’s flexibility rather than coming up with different versions of custom-made tools for each website.

Completely agree. If I were making dozens of websites rather than just the one I work on full time at the moment, then Drupal would be a grand choice.

@Matt Farina

When if comes to your form issues I’m not exactly sure where your issue is. I took a look at your form and the same look is something that can be achieved with FAPI, a tweak in the template.php (to remove the , and some css magic (no crazy theme functions required). A suggestion, no matter which way you choose to go, might be to invest more in CSS.

Thanks for your suggestions. I can remove the : by overriding theme_form_elements() or something like that, but then it affects all forms rather than just one. And it involves copying and pasting the code from there to my own function, then changing it in my own function. Then if in theory there was a security release which changes that function I’d have to make the same change in my function. A bit like forking the code, and potentially a real headache on upgrading to the next version of Drupal if things changed (oh… I’ve spent a *lot* of time upgrading my modules to new Drupal versions before).

If things keep on pace, drupal 7 should (hopefully) be much better with data sources other than nodes.

Again, the whole idea of another Drupal upgrade makes me feel sick knowing how much time I spent last time. Upgrading to Drupal 6 within 24 hours of its release was also a terrible idea… I discovered several major, major issues with regards to forms and race conditions.

@aka006

I nominate you for a position on the Drupal Association Board;)

Haha… thanks. I’d love to spend time doing such things but the reality is this. I have a business to run, money to make, and a baby to support. The idea of spending time on anything else is lovely but almost impossible at the moment at least

@jessa

spot on re. load_node. I really love node_load and node_save, bringing in my own stuff through hook_load and hook_update. But the content type I’ve taken away from being a node is used a lot in big tables with load of them in. I’m not going to do a node_load on each one and have dozens of database queries when one query will do just nicely thanks. Sometimes abstraction is really nice, but for performance abstraction can be terrible.

node_load() performs a query on the node table INNER JOINed with node_revisions and users to retrieve *a single node*. If one is displaying any kind of large listing – like an index listing the title of 100 nodes – we’re then talking about making a minimum of 100 SELECTs just to display a simple table of information.

There’s some overhead involved in sending a query to the database and getting back a result, regardless of how many records are returned. Repeating that overhead dozens of times noticeably degrades performance versus running a single query to get multiple records. If one has contrib modules that make a query when node_invoke_nodeapi() is called, then the situation gets even worse.

If you can make a single query to get a list of nids, you should strongly consider writing that query to retrieve all the fields you intend to display and leaving node_load() out of it.

I’m not trying to bash node_load(). It’s a great function that grabs everything you for a node while ensuring that access control and contributed modules all have their say on the output. When you need to display lots of detail about a small number of nodes it’s perfect. But, it’s the wrong tool for efficiently showing a couple fields from many nodes.