Features support

? huh
You can already export a finder and import it if you need.
If you have a specific function you need then please post a feature request for that.
Don't just ask to integrate with some random module, and not give any practical reason for doing the work.

And ctools is not the solution. To me it's basically some new 3rd party thing that does a lot of what the finder module already did. The hardest thing to maintain about Finder is Finder Views, and I honestly think it is the fault of the Views maintainer for not providing enough information on how Views works. It is impossible to get support about integration with Views. You post a message, and 6 months later someone simply closes it for being an old issue. Or you get yelled at. Guess who maintains ctools?
I maintain a module that is all about exporting nodes, and I have plans to do something more with that in Drupal 7, I am more than capable of developing and maintaining features required without creating dependencies on moduels that will probably just cause me headaches.

@danielb - I completely agree with you. We have spent countless hours working (struggling) with Views, Panels and CTools and it sucks. It is not only the lack of documentation, but the API for working with them in my opinion is overly complicated and clunky to work with. The idea is good, but the code and documentation need to be re-written.

Back to the topic - we are currently using the Finder module and it is working great. We do have a legitimate use case for "auto" importing exported Finders. In other words, we would like to define "default" finders that would be created by the Finder module. Any chance you may be able to support this?

@danielb I'm re-opening this issue as what dereine is asking for is not covered by import/export. cTools exportables work like the Views where modules can provide default views that are not imported into the db but run directly from code. This offers the benefit of making the exported settings easy to override and revert. Updates are made easier as you don't have to remove the old settings and update the new. Just change the default that is in code and you are good. Users who have already overridden the default will not be affected. cTools provides an common API for all of this. It also integrates with the Features module, allowing users to point and click there way to creating a "glue code" module that can be placed into version control and easily be shared across installations.

All of this is really cool powerful stuff. There is a lot of momentum behind this in approach, with cTools becoming the defacto standard. Rather than creating a dependency, module_exists() could be used to optionally include these abilities if cTools is not available. See http://civicactions.com/blog/2009/jul/24/using_chaos_tools_module_create... for more information on implementation.

I hope this information is helpful. I'm tagging the issue for better tracking (see this list for others like it).

All I see is a bunch of words that don't convince me, don't inform me, or address anything I've said in response to this issue. I see a lot of buzz words and that puts me off even further. I don't see any benefits, I don't want to write this, I don't want to maintain this. You use views as an example, but views does not even use ctools.
If you want to import 'default' finders from code that can't be edited in the admin area that is already possible - but you aren't asking for things like specific features or support on how to do that.... you just want me to sit there writing integrations with modules I don't understand or care about - even if their functionality is redundant.
I wonder whether this issue exists just because someone felt like it needed to be an issue, not because finder cannot do what you need it to do.
Yes finder is designed so that the finders are inserted into the db... (like nodes) what's the big deal about that, the user doesn't see that. I don't like modules that support objects coming from places other than the db. I have written two modules "blockreference" and "viewreference" and they were a massive pain to deal with because you can have blocks and views that cannot be queried on - you have to use functions to 'work out' where the views and blocks are - and that is just... shit - in "Viewreference" when you create the CCK field it actually GENERATES A COMPLETE TABLE OF VIEWS so everything can be dealt with consistently. Furthermore modules like finder can't find objects that aren't in the db. So in my view EVERYTHING should be in the db, nothing should ever be defined in a bloody file except the password to the db. I would write the damn php right into the db if I could so I could create a code finder.
And the code to do maintain programmatic finders from another module is easy enough to write.

Hi @danielb,

I think you will see a more and more people requesting this because the features module / context module is really taking off and may become a best practice of how drupal websites are built.

Here is the big picture:

Say your building an frequently asked questions section on your website.
You can use the context module to define contexts and also define what triggers make that context active. You can specify when you are in FAQ context to show certain blocks, set breadcrumbs, set titles, etc.

Once your contexts are defined. You can then jump over to the features module and create a feature, called "Frequently Asked Questions". Then you select what makes up your feature: what contexts, what cck content types, cck fields, blocks, what module dependencies, views, user roles and permissions. Then you can export this feature to a module.

Enable the "Frequently Asked Questions" on another site and the features module sets up all the views, cck field and content types, essentially everything and it's ready to go.

Features can be distributed on a feature server.
If you need to make a change to the feature, simply reexport the feature and put it into your feature server. All the sites using that feature will then see that there feature has a new update to download.

Now combine all of this in an install profile that uses a drush make file and you have yourself an easy deployable distribution like Managing News or Open Atrium.

You could also use the Spaces module to customize or enable/disable the feature per space whether it be an organic group space, site wide, or per user.

So, I think people are requesting ctools integration so that finders can live in files or the database. Having finders defined in files enables site builders to automate building their site by using version control along with features to deploy their website without having to manually point and click on everything to setup their site. If they make a change to the finder, it would be stored in the database where the users can test changes or revert to the file based version at any time.

If you had ctools integration, you could use the features module to bundle the finders into a features module. When the "Frequently Asked Questions" feature is enabled everything would be ready to go. All finders, views, cck, block, roles, would be fully configured and enabled.

Thank you for the work you have done with the Finder module. Let me know if you would like me to elaborate more on any of these modules.

Hopefully that explains some of the benefits.

Just came across this video
http://sf2010.drupal.org/conference/sessions/leveraging-chaos-tool-suite...

It's the ctools exportables part that would fit nicely with this module.

One other resource if your interested.
http://www.lullabot.com/articles/site-development-workflow-keep-it-code

though they forgot to mention .make files + drush in their workflow

Am subscribing in case anything changes on this - we are managing a whole lot of complicated configuration using features & I was hoping to be able to manage our finder the same way.

For what it's worth, just weighing in to say that I stopped using this module for a number of reason -- one of the major ones being that it did not integrate with Features.

I'm reopening this issue as a feature request for Features Integration in the 7.x branch. As gmclelland explains above, Features is quickly becoming a very popular way to develop with Drupal, if not a best practice. It has tons of benefits, and would work great with Finder.

There is a doc page on How to integrate your module with Features, which would be a good place to start.

I'm rewriting finders to be based on ctools exportables.

See http://drupal.org/node/1340622