-
-
Notifications
You must be signed in to change notification settings - Fork 311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metadata definition only in last class hiearchy. #69
Comments
You can use either XML, YAML, or plain PHP for third party bundles. Do we need more? |
OoO. Then there seems to be a bug. I'm using XML and defining rules on the last class in hierarchy, but the rules don't apply. Will do a failing test case later today. |
This seems to be working now, but I'm pretty sure that it didn't the last time I tried to use it. |
Ha. It doesn't work when there are proxies. |
Can you provide some more info? |
As I really don't know how to prepare a proper test case. <?php
/*
* Copyright 2011 Johannes M. Schmitt <[email protected]>
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
namespace JMS\SerializerBundle\Tests\Fixtures;
class OverrideParent
{
protected $prop1;
protected $prop2;
protected $prop3;
protected $prop4;
} <?php
/*
* Copyright 2011 Johannes M. Schmitt <[email protected]>
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
namespace JMS\SerializerBundle\Tests\Fixtures;
class OverrideChild extends OverrideParent
{
} <?xml version="1.0" encoding="UTF-8"?>
<serializer>
<class name="JMS\SerializerBundle\Tests\Fixtures\OverrideChild" xml-root-name="child">
<property name="prop1" exclude="true" />
<property name="prop4" exclude="true" />
</class>
</serializer> If you serialize OverrideChild all properties will be serialized and not just prop2 and prop3. |
Your metadata needs to be specified for the parent as the child does not contain these properties. |
You can't always do that. One perfectly good example is when you are extending a class from another bundle not under your control and that bundle doesn't provide serialization metadata, or you don't like the one it provides. e.g FOSUB. |
You can always define where to load metadata from: jms_serializer:
metadata:
directories:
FOSUB:
namespace_prefix: FOS\UserBundle
path: %kernel.root_dir%/serializer/FOSUB |
The problem with this solution (overriding third-party bundle metadata) is that it can be done only on the application level (on the serializer instance level, to be precise, but we do not want to have multiple serializer instances in one application, right?). But what if two different bundles need to have different behavior? For example lets assume that we have some class Basic in some BundleA: abstract class Basic {
public $id;
} And we have two other bundles that depends on the first one and have two entities: class EntityFromBundleB extends Basic { ... }
class EntityFromBundleC extends Basic { ... } And now suppose that BundleB needs to expose id property and BundleC needs to exclude it. And how one can achieve it without being able to override metadata on per-entity basis? |
Is there a way that you can override or define metadata only for the last class in hierarchy and that would be the rules you'd want the specific object to be serialized by.
The excellent example of where this would come in handy is when you are extending a user model from FOSUB and would like to exclude some properties from being serialized. The bundle doesn't ship with any serialization metadata and even if it would each user could have different expectations of what should and should not be serialized.
This would require some sort of merging all metadata in proper hierarchy.
The text was updated successfully, but these errors were encountered: