Last year, jpetso created the Field Tool project to provide a low-level API for (among other things) getting data in and out of fields in a simple and consistent way (also Transformations for further up the stack, but first things first...). Unfortunately since then he's had had a lot less spare time, so this is a call for help on this obvious Good Idea. Ever been frustrated by the many different ways fields can store values of varying complexity, and having to code your own data import/export handlers for every module you might be using that provides field types? You can help solve this problem!
I am not a fluent coder, nor a great student of programming philosophies, so people who can help in the Field Tool Issue Queue, correcting the mistakes I've already made, contributing more plugins, and helping to build and articulate the big picture of how everything should work, are all desperately needed. People au fait with how fields work in D7, and what's happening in D8, can give us some future-proofing pointers. If you have a module that provides field types, ship a Field Tool plugin with it. If you have a generally useful import/export/migration/aggregation module, consider rewriting it to leverage Field Tool, so you don't have to maintain your own support for all the different field types out there. And of course documentation is vital.
I also don't see any reason why Field Tool shouldn't be at the foundation of lots of other things, like CCK display formatters, or Token module.
We've got to stop reinventing this wheel!
Comments
why?
Why? It seems to be working OK for us to reinvent the wheel when we need it a little wider, thinner, taller, etc.
knaddison blog | Morris Animal Foundation
I trust you're being a little
I trust you're being a little facetious here. A couple of years ago I met a guy who was implacably opposed to the existence of CCK on the grounds that if he needed a new content type, it was easier for him to write a module. I don't know if he's still developing in Drupal. I imagine he's currently waving tiny magnets over hard drive platters because frameworks, languages, computers, and so on just get in the way of his programming genius.
For the rest of us, most of the time we just want a wheel that's circular and rotates. If it's a little wider, thinner, taller, etc. than we expected we'll probably adjust our cart to fit.
I don't particularly want to agonise for ages over the best way to turn a string from (say) a CSV file into a corresponding taxonomy term, and how to turn a taxonomy term into something that's as useful as possible for non-Drupal systems, knowing that the next person who wants the same thing will have to develop their own solution from scratch rather than using or improving mine. Reinventing the wheel can be fun and educational, but it shouldn't be compulsory.