Change to field mapping callback support

I'm kind meh on this, mostly because I hate that whole array('source_field') aspect. I think it's the most cumbersome aspect of the arguments API so I'd love to see if there was a more elegant way to proceed.

I wonder if we could use something like a class name... I guess if I actually spent sometime allowing subfields it would get past the wart that is the arguments. One thing that would be really cool would be the ability to use PHP 5.3's anonymous functions. So we could pass in the $row and $fieldname so the 5.3 code could look like:

  ->callback(function($row, $fieldname) {
    return html_entity_decode(ENT_QUOTES, $row->$fieldname);
  });

So if you needed to do something crazy you could go pull other values from the row. Maybe we give this a slightly different signature callbackAnon() or something so it's not conflicting with the 5.2 and below way of doing things.

I guess what'd like is for it to look more like straight PHP than strange arrays.

I'd really like to see this feature and would be happy to help out. I have a use case whereby I need to build a URL alias based on three different fields from the source.

I could handle them in prepare or prepareRow but I think this could get messy because all the source fields are mapped individually to different destination fields besides the URL alias.

I think being able to fetch multiple source values in a callback would make the solution a lot neater.

I also think this is very much needed. I have a situation where a source field needs to be split and fed into several Drupal fields. I can use the current callbacks system but have to create a private function per task, which is inefficient and inelegant. If there were an option to specify additional arguments I would be able to dynamically specify which Drupal field is being processed and so one single callback function could do the splitting on the basis of the argument.

I've just found a use case of dependant fields that need the value from another field to fill a yes/no

I'll try to post this done properly, but for the moment the patch attached just adds the $mapping context to the callback which was what I needed in case someone else finds it useful.

What about this?

Proper quotes

As an added note to this, I started to use this callbacks functionality for the first time in a custom class, and I couldn't figure out why I was getting an error saying that my callback couldn't be found. After looking at the code that calls the callbacks, I figured out that since it uses call_user_func() (and call_user_func_array() in the latest patch above) instead of something like $this->{$callback}, my callback had to be outside of the class (e.g. in the .module file or another included file). Looking at the example on the doc page, it's not apparent that the callbacks need to be outside of the class.

Is there any reason the callback shouldn't be in the migration class itself? To me, this makes sense, since the addition of the callback is done in the class constructor anyway (I'm no OOP guru, so there very well could be a good reason). If not, I would suggest that the docs page be updated to indicate that the callbacks need to be outside of the migration class in order to be found. I'll be happy to change the docs myself, but I want to make sure it's the correct thing to do first.

Sigh, ignore that last comment. I misread the docs.

As shown, each callback may be either a standalone function or an object and method. (These are passed directly as the first argument to call_user_func().)

Back to my hole...

I like the idea of the additive approach. See the attached patch which adds callback() and keeps backwards compatibility with callbacks().

Thus, you can do something like this:

$this->addFieldMapping('body', 'body')
  ->callbacks(array($this, 'addTitlePrefix'), 'drupal_strtoupper')
  ->callback('html_entity_decode', ENT_QUOTES, 'ISO8859-1')
  ->callback(array($this, 'doSomething'), 'param1', 'param2');

Renamed the patch.

FYI, I'm using this solution heavily on a big site migration, chaining both callback() and callbacks(). It improves the DX quite a bit.

Mike, it was great to meet you at DrupalCamp STL. Thanks for the great presentation, and for all your hard work on the Migrate module.

This is awesome and works fantastic.