Hello to the other maintainers.
Now I've fixed the menu access bug on D6 and looked at the interface, I can see it looks very different to what's gone before, and I'm wondering what the plan is or was...
was the intention to have the same sort of hook selection form and hook templates as D5? Where were was that going to fit into the interface? Or was it going to be something different?

If you've got plans or you had plans... let me know :)


pkej’s picture

I would like:

Pulling node-types and fields to export to the module.
Pulling views and node-types the views depend on to the module.
Pulling content to export to the module.

I would dream of:

Form builder w/scaffoldings for the callbacks, ie. something a bit like CCK but for building administration forms and node form additions.

joachim’s picture

For now, I've ported the D5 interface to work on D6, as the 6-1 branch is too complex for me to get my head round in the time I have.

Support for hooks from other modules would be nice -- eg taxonomy module has at least one hook; then there's lots of contrib modules that have hooks. I guess that would have to wait until contrib docs are on api.d.org, or contrib modules would have to provide info for module_builder.

joachim’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
RockyRoad’s picture

Hi all,

What about saving the parsed version of downloaded hooks, as php code, something like:

$source_code = <<<EOT
global \$hook_groups;
\$hook_groups = 

$source_code .=  var_export($hook_groups, TRUE) . ";\n";
$destination = file_directory_path() . '/hook_groups.inc';
if (!file_put_contents($destination, $source_code))
  trigger_error("Failed to write file  $destination");

and elsewhere:

include(file_directory_path() . '/hook_groups.inc');
if (!isset($hook_groups)) {
  // TODO download and parse hooks

"hook_groups" may not be the right name, I've not really studied the code yet (working on something else).

This would probably be more efficient, since downloaded html page would be parsed only once. It would also allow to use hook_groups.inc in other, lighter contexts, even offline with CLI php.

If possible, I would also like to find hook information in generated phpdoc blocks.

Best regards,

joachim’s picture

Parsing the downloaded hook data only once would certainly be more elegant.
But I don't think the speed gain would be appreciable -- it doesn't take that long at the moment to generate a new module, does it? What would the other applications be, such as on the CLI?
So not something I'm going to implement myself unless I find myself stuck on a train one of these days, but if someone else wants to take it on I'll consider a patch.

I think hook groups for major contrib modules such as CCK and views could be useful. It's mostly a question of finding a stable and fixed source to download the data from.

RockyRoad’s picture

Hi Joachim,

Thanks for your answer. Maybe I should add a few explanations.

Loading any administrative page is very long on my localhost Drupal dev site. It's natural since all checks are on and I may load (too) many (some unstable) modules there to test them.

When you generate some code, you would often do several tries before getting the right settings for your project.

I have no use for a module generator loaded every day on a production site. In my view, a Drupal code generator has not to be sensu-stricto a Drupal module — Could Developer modules page be retitled "Contributed Developer Tools and Modules" ?.

Personally I often use XQuery or XSLT to generate code, so I'd save parsed API as XML. Some may prefer Velocity or whatever.

I understand that using Drupal forms API can be handy for the GUI part. But don't modern software architectures separate business logic and presentation ?

Anyway I love the idea of a code generator based on official API and encouraging best coding practices.

At the moment I'm working on several other projects so I can't take part now to module_builder development. But if you agreed I'd be happy to join my efforts to yours on this asap.

Best regards,

joachim’s picture

Ah, right, I'm starting to see what you mean :)
If we saved parsed data, it might as well be parsed to PHP code. Saving it as XML just means parsing both times, downloading and generating.
But we could implement different parsers, and one or several of them could run when data is downloaded.
I don't have time to work on this right now either, but feel free to open a new feature request for this :)

RockyRoad’s picture

Hi Joachim,

I'm afraid my idea about XML is just another way to do things, substantially another project idea.
I already did something probably equivalent by parsing directly http://api.drupal.org/api/group/hooks/6 with Xquery. It's not yet polished enough to be published (and it's quite trivial), it's just for personal use for now.

Sure there no point, from parsing in php, to convert data to xml and back, unless xml is re-used by other means.
Note that I only suggested to save data as php code. I talked about xml as an example use of it (in some satellite tool).

I realise that the most interesting part of ModuleBuilder is probably the GUI, so it probably better to focus on that.

Best regards,

joachim’s picture

@RockyRoad: I've now got parts of the code to a point where parsing on hook download and saving the result seems a good idea.
I've no idea how best to save the data though. Any suggestions? Feel free to open a new issue for this if you're still interested.

SLIU’s picture

I discovered module_builder and this thread when I was doing a research to support my feature request: http://drupal.org/node/533192 .

I also found a dead module that never took off: http://drupal.org/project/builder .

Since this thread is about Roadmap, perhaps I am allowed to do some brainstorming about the future including D7 and D8 while you guys are still working on D6. :)

I am not sure how the community and core team would respond to my feature request. But inspired by the way of using module_builder with drush, I can imagine a non-destructive template/meta data based module repository implemented in a drush like environment outside of Drupal file system. By non-destructive I mean this system would parse existing drupal contributed modules, save the information in meta data files, and then using templates (PHP engine or XSLT) to generate module files no different than hand made code.

The goal is beyond scaffolding (like in RoR) or wizard (like in IDE) but a flexible code generator that separates declarative programming from imperative programming and evolves with the Drupal core.

A practical way to do this is to codify the instructions on Updating your modules in the forms of .info/.ini/XML/YAML (whatever), then design and implement code templates in the fashion of theme engine or XSLT. We can also borrow ideas from modules coder. The goal of this is not only make module building easy but robust, understandable and maintainable. Hopefully with the same meta data code base, we can easily generate Drupal modules for any version of core with enough meta data for module API. This would also make the #D7CX effort much easier.

Any one interested?

joachim’s picture

@RockyRoad: parsing the code and saving the result at download time rather than generate time is now done. In the end I went for what seemed simplest, which was to store a PHP serialized array in a file.
I've also added a hook to allow other modules to declare their hook data. Obviously for now, all that's using this is the stuff we register on behalf of core and... module builder registering its own hook ;)

@SLIU: Drush support is pretty good now; just added a heap of stuff today. One thing I added is the ability to add new hooks to existing module files rather than write a whole module file from scratch -- useful for ongoing development of a module. Take a look :)

SLIU’s picture

@joachim The drush version of module_builder is awesome. I put all the drush commands in one shell script file (or makefile, build.xml) so that I can build and enable a module without touching the web UI at all. Something like:

drush mb my_module menu cron nodeapi --name="My module" --dep="forum views" --write
drush enable my_module

In reality this doesn't work yet because what module_builder generated are boilerplate code instead of working programs. I have to manually edit those "TODO" lines and add my own code.

How about a drush implementation of GNU build system? Then we will be one step closer to a drush version of APT.

SLIU’s picture

I think the main difference between a boilerplate based code generator and a configuration based build system is "machines teach humans to write code" v.s. "humans teach machines to write code". :)

joachim’s picture

Cool! glad you find it useful :)
I do the same thing -- start off module code without touching either the web UI or the Finder.

drush mb my_module menu cron nodeapi --name="My module" --dep="forum views" --write
drush enable my_module

You can in fact say:

drush mb my_module menu cron nodeapi --name="My module" --dep="forum views" --go

which writes and then enables -- though of course none of your code is in there yet.

I'm not sure how MB could generate programs though, or be like GNU build system. But by all means suggest features or post patches! :D

SLIU’s picture

I think perhaps MB can learn something from drush in a way that it has its own versioning system that can deal with all core versions form D5 all the way down to D6, D7, ... .

This could be achieved by making MB more modular to leverage existing information from available file system info, configuration files (.info, .module, .install, .profile, .view, etc, etc) or even the source code itself. The ideas is to separate data from algorithm and assemble (compile?) working code from components.

I will look into the design of GNU build system and see how much we can borrow.

DamienMcKenna’s picture

How about merging in Features and making it work completely off existing hooks? =)

joachim’s picture

Can you explain what you mean? I can't see much of a connection between Module builder and Features.

DamienMcKenna’s picture

Features builds a module out of exportables. Module Builder builds skeleton modules. They both *build* modules. Maybe a starting point would be to have an option for ModuleBuilder to add the necessary items for Features to work so that someone could just copy the .module file from ModuleBuilder and use it with their Feature? I guess, though, that this is getting onto a topic unrelated to this specific ticket.

joachim’s picture

Hmmm you're right that they're both modules, but the intent is very different.

You'd never edit the code of a Feature module, surely, because anytime you updated the Feature you'd lose your code. It's machine-written and meant to stay that way.
Whereas module builder writes a scaffold that you then fill with your own code.

There is actually an --add option already in module builder, so if you did want to add hooks to a module file that Features had already written, you could use that. But as I say, Features will clobber your work!

joachim’s picture

Title: Roadmap? Plans for D6? » Roadmap? Plans for D7?

Updating the title... keeping this open as a general discussion space :)

joachim’s picture

I've filed a bunch of issues concerning hook groups which will be my focus at least for the time being.

Also, now that we have nice OO code for the code generation, this could be expanded to write other thingss like .test files (see the issue for that), or even themes.

joachim’s picture

Oh, and hook templates for D7: please post patches -- #1106566: update hook presets for Drupal 7 :)

doublejosh’s picture

Shouldn't hook settings be included?

joachim’s picture

hook settings? can you explain more what you mean?

doublejosh’s picture

Looks like it's not actually a hook. Just a technique for building simple admin settings form pages.

function MYMODULE_menu() {
  $items = array();
  $items['admin/settings/mymodule'] = array(
    'title' => 'My Module Settings',
    'description' => 'Quick description.',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('MYMODULE_settings'),
    'access arguments' => array('administer site configuration'),
  return $items;
function MYMODULE_settings() {
  $form['#prefix'] = "My explanation.";
  $form['my_setting'] = array(
    '#type' => 'textfield',
    '#title' => t('My Label'),
    '#default_value' => variable_get('my_setting',NULL),
    '#description' => t('Description of my setting.'),
  $form = system_settings_form($form);
  return $form;

Perhaps this is not the preferred way, or longer available in D7.

joachim’s picture

It used to be a hook in 4.something. Now it's just a pattern which is still fairly standard in core and contrib.

ZenDoodles’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev

Hi @joachim Thanks for your work on this module. I was just having a look around at the code and the issue queue, and I had some input.

It makes sense to me that a major rewrite like that should have it's own branch in git. This avoids having things like the Xmodule_builder_* functions in the current branch. I like the direction the code is going with objectification, but those really need to go along with some general clean up, so there's a lot of work left to do. It seems like there are things left over from as far back as 4.7.x.

I would really like to see if there's any way this module could leverage the api module. The module builder storage scheme for api/hook documentation (hooks_processed.php) is less than optimal, and any rewrite will probably need to address that. If we could leverage the api module which already parses all of that anyway, it would be very nice.

In leu of that, it would be nice to have a configuration option for using local files instead of pulling them down from d.o. Given this path, I would also be inclined to add options for which modules to parse for api documentation, and to just automatically parse the local core files on install.

As a less architectural, more immediate suggestion, IMO the config pages should be broken up more logically with all the settings for building a module being on one tab (or maybe fieldset) and all the settings for parsing/updating the hooks in another. I think this would only move the path setting to the update tab right now. Also, validation of the storage path should be done before storing a bad path, not when we want to update/parse. That should be as simple as moving those bits to a form _validate() function.

(also not sure how a roadmap for Drupal 7 issue is attached to 6.x) :D

joachim’s picture

> it would be nice to have a configuration option for using local files instead of pulling them down from d.o

That happens already on D7. On D6, there are no local files, so they have to be obtained from d.org.