Switch scope of the Drupal Composer namespace

fsdfsd

Here's a screenshot.

Also, there should be

<?php
  drush_set_context('DRUSH_EXECUTION_COMPLETED', TRUE); 
?>

[EDIT] Pushed it up to Drupal.org webmaters: #1419818: Composer: Rob Loach as maintainer.

I'm keep the old module information here for book-keeping.....

Composer allows users to rapidly add and change CCK fields, Taxonomies, menus (well, soon), and eventually other Drupal objects by writing an extremely simple text file with an easily readable and compact syntax.

The motivations behind Composer:
1) to allow a site's basic structural elements to be prototyped and configured extremely rapidly even if they don't yet exist anywhere (as, say, a Features module feature).
2) to create a system wherein a developer can easily and rapidly change a large number of CCK fields, taxonomies, menus, etc. in order to demonstrate those changes to clients during the development process without wasting hours clicking around in clunky interfaces.
3) to bring us poor developers as close as possible to being able to simply feed a client email into a Drupal site and have the site re-configure itself automatically :)

Composer is a lot like Patterns, except that it doesn't seek to provide a complete and unified solution for all possible objects and use cases, and instead focuses on simplicity. Composer relies on defaults to minimize the complexity of the hand-written import files. It comes with a pretty decent set of defaults for each object, but more advanced users (i.e. developers) can customize these defaults to their own needs.

Here's some example CCK field syntax just to give you a taste:

[page] First page of node form
  [fieldset] Personal info
    [textfield] Name
    [date:range -25 +1|granularity ymd] Date of birth
    [select:options(Male,Female,Martian)|multiple] Gender
[page] Second page of node form
  [fieldset] Other information
    [textarea:required] Explain your dreams and deepest desires
    [file:multiple] Upload supporting documents, images, etc.
    [checkbox] I understand that aforementioned dreams and deepest desires will never be realized

As you can see, Composer supports multi-page node forms via the Multistep module.

And some Taxonomy syntax:

First parent term to create from scratch
  Child term 1
  Child term 2 [description:This is the term's description.]
Second already-existing parent term to update [tid:52]
  Child term 3
    Child of child term
  Child term 4

I'm definitely interested in having a co-maintainer or two on board, so please feel free to get in touch if you're interested.

Why did you write this module? Why did you design yet another language for describing information architecture?
I'm definitely not interested in explaining why this module is better than/different from/[more|less] useful than [Patterns|Features|clicking around in the admin interface]. If it's useful to you, awesome. It's useful to me too. Also, I am aware that designing yet another syntax in the age of YAML/XML/JSON/whatever else may seem not only pointless but also harmful to the quest for standards and compliance thereto. But I find that most developers aren't interested in manually typing out YAML/XML. Moreover, converting plain-English(/etc.) client change requests and technical specifications into those formats is not trivial. On the other hand, converting requests and specifications into Composer's syntax is pretty easy, usually involving little else besides adding a few square brackets and spaces here and there (especially if you do a good job setting up your defaults).