Add @Virtual annotation

[anyx]

@virtual - method annotation, which allow to add calculated fields to serialized object.

For exampe object of class:

namespace JMS\SerializerBundle\Tests\Fixtures;

use JMS\SerializerBundle\Annotation\SerializedName;
use JMS\SerializerBundle\Annotation\Virtual;

class ObjectWithVirtualProperty
{

    protected $existField = 'value';

    /**
     *
     * @Virtual(field="foo")
     */
    public function getValue() {
        return 'bar';
    }
}

to be serialized as: '{"foo":"bar","exist_field":"value"}'

[schmittjoh]

If we add something like this, then it needs to be in the GraphNavigator instead of the different visitors.

Currently, this also bypasses all exclusion strategies that have been set. To solve this, you probably need to create a sub-class of PropertyMetadata, sth like VirtualPropertyMetadata.

But in general, I think this would be indeed useful.

[michelsalib]

I don't like the idea of Virtual. Why not using Expose ?

[schmittjoh]

This is mostly useful for data that does not exist on a property, but for example is the combination of properties, or calculated in some other fashion.

<?php

class User
{
    private $firstname;
    private $lastname;

    /** @Virtual("fullname") */
    public function getFullname()
    {
        return $this->firstname.' '.$this->lastname;
    }
}

[michelsalib]

@schmittjoh I already got the point of this annotation. It makes perfect sense. I am jut not found of the name.

JABX allows to use XMLElement on method, which is our equivalent of Expose (I cannot check at the moment because java website is down). My point is what prevents us to use the Expose annotation on methods ?

[anyx]

@schmittjoh, i removed code from visitors and created VirtualPropertyMetadata as you said. As for annotation name, i prefer Virtual to Expose. If current realization is acceptable, we can discuss annotation name.

[michelsalib]

I won't argue too much, I will just follow @schmittjoh decision.

[schmittjoh]

I think we need to remove the "field" attribute from the @virtual annotation (and instead use some transformation of the method name). Regarding @expose, I don't think it's wise to re-use this as it used in another sense already, and would have a different behavior depending on whether it is declared on properties, or on methods. Maybe we can be more explicit, and call it @VirtualProperty?

Also, all the other annotations like @SerializedName, @groups, @expose, @exclude, @XmlAttribute, @XmlValue, etc. should be available for methods as well. @SerializedName would replace the "field" attribute that is currently on the @virtual annotation.

There are also a few CS issues in your code, mostly indentation, and whitespace, could you check them as well?

Another thought, does it make sense to provide a setter for virtual properties?

[michelsalib]

@schmittjoh I agree with you.

Making this available for setter is IMO a bad idea. The developer will have to be very (too much) careful about its use, and the consumer will definitely be confused about which property to use (the normal or the virtual one).

[anyx]

I renamed annotation into VirtualProperty and modified AnnotationDriver: now other property annotations work.

[schmittjoh]

What about removing this? It's redundant with @SerializedName.

[anyx]

Yes, but if we remove this, VirtualProperty annotation will work only together with SerializedName. If you sure, that this variant is better, i can try remove this.

[schmittjoh]

I think we could use some smart default based on the method name.

if ('get' === substr($method, 0, 3)) {
    $name = lcfirst(substr($method, 3));
} else {
    $name = $method;
}

[schmittjoh]

The implementation looks better now.

Would you mind also updating the Yaml, and XML drivers?

[anyx]

I removed $field property from annotation and implement same logic for other drivers. Now we have little copy-pasted code in metadata drivers. Maybe create abstract metadata driver?
Also "SerializedName" isn't involved in sorting properties (i mean "AccessorOrder").

[schmittjoh]

Thanks for your efforts.

I think you can inline the code which is responsible for determining the virtual property name into the constructor of VirtualPropertyMetadata, and simply pass ReflectionMethod instead of $name as argument.

Regarding serialized name, I don't think we can change this without incurring additional runtime overhead. What you can do however, is define a custom property order which respects the serialized name for your class.

[anyx]

I have changed constructor VirtualPropertyMetadata. Now it accepts method name in second argument. In the constructor we can determine $reflection property as new \ReflectionMethod, but i did not do this. Add this?

[ruudk]

Would it be possible to also allow this for deserializing?

I want to give the user the possibility to send an extra variable called where he can set some extra settings when creating new resources. I don't want this to end up in the serialized state of the object. It is only available for deserialized objects.

[anyx]

@ruudk, i don't understand exactly what you mean. Why is "PostDeserialize" annotation not suitable? Can you give example of usage?

[anyx]

@schmittjoh, did you see last commits? Is current state acceptable?

[schmittjoh]

Apart from a few CS issues, it looks good.

Hope that I'll be able to test it a bit more thoroughly tomorrow.

[Spea]

@schmittjoh Any updates when this will/can be merged?

[schmittjoh]

Probably during sflive.

On Thu, May 31, 2012 at 8:06 AM, Martin Parsiegla <
reply@reply.github.com

wrote:

@schmittjoh Any updates when this will/can be merged?

---

Reply to this email directly or view it on GitHub:

#109 (comment)

[Spea]

Ok, thank you for the update.

[schmittjoh]

Hey, thanks for your patience.

I had to make a few changes to bring it up to speed with master, and also a few minor CS fixes, but apart from that I merged it completely.

[anyx]

Cool, thanks

[slaur]

This is awesome, thanks @anyx and @schmittjoh