CCK/Views to Module Conversion

What we want to have is two layers of standalone modules. The first is the content-type, and the second is the "views" of said content.

Content-Type Modules

These could take advantage of the new Fields development in D7. It would be possible to come up with a loose framework of what a module like this would look like (a template, if you will), and then programatically generate it whenever an export is requested through some Drupal admin GUI. The key here is to make it as human-readable as possible. This allows for any simple changes, as well as possible custom handling of content (e.g. easily add hooks on creation/deletion of nodes).

Workflow here could be quickly mocking up content-types in a GUI, and then exporting them to start versioning them, and so that easy changes can be made from the programmer's perspective.

Views Modules

What we want here is already complete in a sense. Below is an excerpt of your standard export of a view in Drupal.

$view = new view;
$view->name = 'dealers';
$view->description = 'Listing of available dealers';
$view->tag = 'Dealers';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('fields', array(
    ...
));

However, in addition to being extremely hard to modify (who knows the exact options you can override and the order in which Views expects their parameters?) it also relies on Views to produce anything useful. We want to break that dependency -- include just enough code so that it can create whichever page or block that is needed. Again, the advantage here is that we have complete control over this module, and can add custom functionality or extend it into a completely different and complex module if we wish.

Workflow here could be creating an initial view of some content-type, exporting it in this new fashion, and versioning it. From there many more powerful customizations can be made than allowed in the Views edit page. (Ever tried to show a list of links to nodes alphabetically but only showing the first three of each letter in the alphabet?)

Backporting

Of course there is some merit in having a GUI available -- if there is enough time then it would make sense to make this process bidirectional. Granted, it would only remain that way if the programmatic changes made could also be accomplished via the GUI. This would also limit the syntax of the file somewhat if it needs to be read in and interpreted consistently.

An interesting way of doing this would be in a completely passive and automatic way -- keep corresponding textual modules to a subset or to all content-types and views. If the modification dates on said files changes, read and import them into Drupal. If they are changed in the Drupal administration interface, then output them overtop of the existing files. This makes for a very powerful dual-track system.

Timeline

• weeks 1-2: plan out desired features (i.e. layout of exported files, GUI interface to control said exporting and potentially importing); dialogue with Drupal community members (perhaps Barry Jaspan regarding D7 Fields?)
• weeks 3-5: main coding of standalone content-type modules
• weeks 6-9: main coding of standalone views modules
• weeks 10-11: bugfixing, improving syntax/output of modules, ensuring extensibility
• week 12: work on ability to import changes back into Drupal if time available

Can any of the mentors on here think of cases where they might find something like this useful? What kind of features would be most important to you and the Drupal community?

Hi,

I believe [features] would be a good place to start.

cheers