I did have a look into the "resolve target entity listener", but it wasn't 
really what I needed. 

The solution was actually quite simple. As I have a BaseEntity class which 
everything extends, I know that any classes implementing Sluggable will 
(should) also be a descendant of BaseEntity. I switched from using "Mapped 
Superclass" inheritance mapping to "Class Table" inheritance, which allowed 
me to set the relatedSluggableEntity field to be a relationship with 
BaseEntity. In the relatedSluggableEntity setter, I type hint the Sluggable 
interface. 

On Tuesday, 4 February 2014 10:10:11 UTC, Holtkamp wrote:
>
> Not 100% sure whether I understand the question, but maybe this can help?
>
>
> http://doctrine-orm.readthedocs.org/en/latest/cookbook/resolve-target-entity-listener.html
>
> Only then you should 'at runtime' determine which Entity implements the 
> interface exactly and process/load that one appropriately. 
>
> Would be nice if you could share your findings ;)
>
> Cheers!
>
>
>
>
> On 3 February 2014 16:50, Josh Buckley 
> <[email protected]<javascript:>
> > wrote:
>
>> I'm creating an entity class which represents a MenuItem. This can have 
>> a one-to-one relation with any class implementing SluggableInterface.
>>
>> As the MenuItem should be able to relate to any SluggableInterface class 
>> (existing and future), I cannot specify a normal doctrine relation as there 
>> isn't a specific related entity.
>>
>> I've come up with some possible solutions, but they have drawbacks:
>>
>>    1. 
>>    
>>    Create an ObjectReference entity to hold the class name and id of the 
>>    related object. This class would then have a getObject() method to 
>>    construct and return the necessary object. *The drawback here is you 
>>    can't (cleanly, at least) access doctrine from within the entity.*
>>    2. 
>>    
>>    Create an object_reference type to convert the object to a string 
>>    containing the class name and id. *The issue again is accessing 
>>    doctrine in the Type class to retrieve the object.*
>>    3. 
>>    
>>    I've not tried this one yet, but create a class listening to doctrine 
>>    events, then checking for fields with a custom annotation, and do the 
>>    Object->String and vice-versa conversion there.
>>    
>> Before I start investigating #3, does anyone know of a "proper" or 
>> alternative way to do this?
>>  
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "doctrine-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/doctrine-user.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to