Hydrator property mapping.

[j]

Hello there!

I have a few features I want to see if you're interested in implementing before I create my own generators.

Basically, I have data I want to hydrate into an object but with different field names.

i.e.)

$user = $hydrator->hydrate(array('fn' => 'John', 'ln' => 'Doe'), new User());

echo $user->firstName; // "John"
echo $user->lastName; // "Doe"

This shouldn't be too hard to implement i don't think. It'd also be nice to extract it back into the shortened fields. It's just a matter of where to put this configuration or at least make it possible.

I'd like to perhaps add annotations to do the mapping (but I can do that within my application). It'd just be great if it were possible right now. It'd be a simple way to do DTO to domain object mapping and back.

Let me know if you feel this can belong here and I where you feel the configuration should be and I can give you a PR.

[Ocramius]

@j I like the feature and it's surely worth giving it a shot, especially when considering that DB fields could be very different from entity field.
There's a problem with this approach anyway: proxy naming.
You may look at #10 for that, but basically, the idea is to generate proxy class names based on the options of the proxy itself, like:

SomeGeneratedHydrator_MappedProperties_fn_firstName_ln_lastName etc etc.

The problem I currently encounter is encoding the parameters used to generate the proxy, which is tricky given the small set of characters allowed in class names [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*

Some approaches may be to use non-ASCII delimiters such as (ノಠ益ಠ)ノ彡┻━┻ (joking, but that's essentially the trick) and throwing exceptions on invalid options. Basically a transliteration of http_build_query.

To make an example:

echo urldecode(http_build_query(['map_properties'=>true,'map' => ['fn' => 'firstName', 'ln' => 'lastName']]));

Produces

map_properties=1&map[fn]=firstName&map[ln]=lastName

We want

map_propertiesლ1ಠmapノfn彡ლfirstNameಠmapノln彡ლlastName

in the class name.

Thoughts?

[j]

There's always md5/sha1 hashes :P

Other alternatives may be to have a factory instance have a suffix configuration option and users can just create another instance of a factory with a different suffix.

[Ocramius]

@j hashes can (rarely) collide - they are not thought for this use case and I really want to avoid them. I think base64 will do the trick :)

[Ocramius]

But yes, factories should be immutable

[Ocramius]

I think I fixed the problem in #59 - now the factory-specific config can be injected :)

[Ocramius]

@j I moved this to Ocramius/GeneratedHydrator#5