Roadmap? Plans for D6?

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.

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.

Hi all,

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

and elsewhere:

"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,

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.

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,
Michelle

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 :)

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,
Michelle

@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.

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?

@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 :)

@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:

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.

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". :)

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

You can in fact say:

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

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.