Larry Garfield wrote:
On Tuesday 21 February 2006 07:26, Angie Byron wrote:
At DrupalCon, a few of us had talked about how handy it would be to have a module that automatically generated "scaffolding" for modules, both to help new developers as well as to speed up the process of creating custom modules for Drupal veterans.
As a result of a major bout of insomnia, I am pleased to announce that Module Builder Module 1.0 has been committed to CVS, and even pretty much works! ;) You can check it out at:
OK, I've not actually looked at it yet, so I can't comment on how good/late-night the code is, but my knee-jerk reaction is that I don't like code generation in the first place. If the code is sufficiently boilerplate that it can be auto-generated, then it's sufficiently boilerplate that it should be written as a single routine and called with paramters. That's the logic behind functions and variables. :-)
As a for-instance:
hook_load(), hook_insert(), and hook_update() are horribly redundant. All three do the same thing in almost any node. They select/insert/delete fields from a table, using almost the same code. Sometimes there will be an extra table to manipulate, but there's still almost always a basic node++ table. And the fields have to be specified in all of them. Ick!
The solution, however, isn't to have something that auto-generates those functions. It's to let the module define the table and fields once and then let node.module handle the basic S-I-D. Save those hooks for stuff that's actually interesting, and reduce the amount of code, too.
I'm thinking something like:
nodename_fields() { return array('nodenametable' => array('field1', 'field2', 'field3')); }
That would also allow node_load() to return an "empty node" of the correct type, which would help with E_ALL compliance.
(Yes, this is something I've been thinking about for some time, but have been holding back on actually trying to implement because I didn't want to introduce a change of that size when we've been "almost ready to get 4.7 out the door" since, uh, November. Hi, Ber! <g> I actually did something very similar to this at work, so I know it can be done.)
So yeah, code generation in general gets a -1 for me in favor of more powerful and generalized polymorphic code.
This is the most idiotic post I have read on this list so far. It starts with "I've not actually looked at it yet"... Well, if you haven't looked at it, why do you comment on it ? Do we care if you like code generation or not ? Do we care if you like "powerful and generalized polymorphic code" ? That's not the topic I think. This module is about building a module skeleton to make developers job easier. How do you think PHP extensions are written ? People use ext_skel or pecl CodeGen and it saves them a lot of time and makes it more fun to hack something fast. That's one thing that largely contributed to PHP success. I am personally very thankful to the people who wrote Module_builder and will start to use it straight away even if it's not "powerful and generalized polymorphic code" :p -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - blog