Hopefully coming to a Drupal CVS account near you soon, tales have been told of CivicSpace's "packages" concept. Need to add wiki capability to your site, which is a mixture of config (roles, views, settings, etc.) and modules, after the fact? Deploy the wiki "package". /me pokes Kieran and nedjo....

Install profiles are of course the other part of this, but only for fresh, brand new sites. There are some tricks for updating -- e.g. make an install_profile.module that has a schema, and you can put anything you want in the update hooks over time.

In having built a couple of install profiles now, it's clear to me that the concept of packages is needed: I don't want to just cut and paste my TinyMCE config code (which makes up a 1/3rd of my install profile) into install profile number 2. And how about wanting to configure this on an already running site?

Spurred on by the Lullabot "Deprecated!" podcast a month or so back, and Nate's comments that the Webform module was probably deprecated and could be replaced by a mixture of CCK and other modules, I thought I'd take a stab at proving him true when faced with creating an online library card application recently.

What I ended up with (quite happily, I may add) was a Library Card Application content type (brought to you via Content module and CCK), a Library Card Applications view (via Views), and an email Action (from the Action module). And to glue everything together, a custom module (librarycard_glue) that used hook_form_alter() to hide the content type's title field and automatically populated the title with the application name and datetime. This custom module also defined an action to be triggered on form submit, notifying a person designated using the Actions UI.

When I embarked, I'd had high hopes that I could eventually develop this module into an all-purpose glue module that others could use to "glue" similar content types into Webform style forms. But upon completion of my implementation, I realized that the amount of configuration burden that's put on the user would make this something of a bear to describe and support. Upon installing this module, a user would still have to:

1. define a custom content type
2. define a view
3. setup their actions

It seemed to provide too little, while asking so much of the user. Perhaps I'm missing a better way of doing this. I'd love to join forces with someone who has some bright ideas I don't. But at the current time, I think your term "gray zone" describes the scenario perfectly.

mlsamuelson

I think the CCK/Views approach lends itself to being incredibly awesome in terms of being able to create content types that are exactly what you want, and displayed exactly how you want them, and with modules like content template, it makes it very straightforward to theme these things, and with imagefield and image cache, it makes setting up REAL simple ways to contribute content for users for a site.

I think Jeff R makes a good point in his saving the world article when he points to applications like Automator being easy to plug legos together to write simple applications.

While it's incredible the amount of power a few CCK modules can give you, sometimes finding out what each of them do can take a long time, (granted not as long as trying to figure it out yourself!), and setting up a test environment specifically to try these configurations can become monotonous, at least until you are familiar with how certain modules interact.

What I enjoy in particular about Automator is that it lowers the bar and welcomes experimentation. Granted you're not constructing content management systems with it, but if at some point down the road there was some method to play with all the different fields at once, or online somewhere, or even with a drag and drop interface, I think it would allow an intermediate or even novice developer to rapidly test different configurations on how content types or views might work.

Another idea could be some way to allow someone with an interesting or useful combination of cck/views related modules to roll that into a glued module to share with others. For example, if someone has a neat content type called "Products" that displayed descriptive text, provided a field for an inline image, maybe some styled subheadings, and a thumbnail thickbox gallery, and relied on: cck, views, imagecache, imagefield, contemplate, and thickbox... maybe if there was another tab for the content type (or a giant red button!) that exported not just the code for the content type, but actually collected all the contrib modules, and allowed that developer to share that "products page with inline image, subheadings, thumbnail thickbox gallery" glue module easily with someone else... well that would be cool, and provide the user installing that module the flexibility to add/remove fields easily so long as they understand cck/views.

Regardless I think the system that is in place currently is excellent and can't wait to see what direction this all takes.

I know you guys are up on this 'cause I see the 'bots out there in the issue queues for these features, but I thought I'd mention it as what I am running into the most. Especially I see the need to come up with a good solution in core, and then have the same format/technique filter down into contrib, and eventually, I could see it being standard for any module that adds data handling to be required or at least recommended to implement Data API/crud hooks/functions.

Actions in core for D6 is huge, as are the modules out there starting to tie actions and views together. In short order we could have not only the most powerful CMS in terms of presenting content to users, but even building advanced, custom interfaces for users and admins.