One of the required backends necessary for data morphing. The term recto comes from the terms meaning front and back of a page in a bound item such as a book. The provided instance to this attribute via constructor argument will need to consume the Data::Morph::Role::Backend role.

Which backend that ends up in this slot or the "verso" slot doesn't really matter. Data morphing is a two way street of awesomeness that operates based on the type of the input.

One of the required backends necessary for data morphing. The term verso comes from the terms meaning front and back of a page in a bound item such as a book. The provided instance to this attribute via constructor argument will need to consume the Data::Morph::Role::Backend role.

Which backend that ends up in this slot or the "recto" slot doesn't really matter. Data morphing is a two way street of awesomeness that operates based on the type of the input.

In order to properly morph data from one source to another, a map needs to be provided that meets the above type constraint. It looks like a bunch of gobbledygook, but the structure and semantics are rather simple.

A map is nothing more than a array of hashes that define directives to the recto and verso stored backends. Each directive to a backend can define a simple string to indicate to use the same key for reading and writing values. Otherwise, a hash is used where the keys 'read' and 'write' are used. And if there should be a post or pre process that occurs for a read or write, respectively, the value for 'read' or 'write' should be an array of the directive and a coderef to be executed. The coderef will receive the value and only the value. The return value from the coderef will used post read or pre write.

The directives are specific to which ever backends are being used. Each has their own exepctation.

The recto side uses get_* and set_* methods (or attribute readers/writers), while the verso side uses a single method or attribute for reading and writing. Also note that the 'bar' value gets a string appended on the verso side that needs to be stripped before morphing back.

Each hash in the map array is executed in the order in which it is defined. This is important if there are order dependant operations.

If a data element only flows one way through the process, do not define a write element for the given recto/verso, but just a read element.

As an example, suppose the object on one side of the transaction needs a constant not provided by the incoming data. With read-only elements and a coderef, this constant can be provided:

This method is where the magic happens. The passed in instance is subjected to "match_on_type" in Moose::Util::TypeConstraints with the value from "morpher" used as the potential execution branches. Whether it is recto -> verso or verso -> recto, the map is read and a return value produced.