Small contribution to the discussion. So for XML that means support for one of: http://xml.silmaril.ie/includes.html, where XInclude <http://www.w3.org/TR/xinclude/> would be the preferred one to be able to use XML Schema for validations..
Currently the XmlDriver uses SimpleXMLElement for parsing, it seems it supports XInclude <http://objectmix.com/php/500990-simplexml-libxml-options-xinclude.html>, so you could experiment with tweaking the XmlDriver::loadMappingFile() function a bit. This kind of support might be useful indeed. Cheers On 26 November 2014 at 11:30, Sebastian Krebs <[email protected]> wrote: > > > 2014-11-26 9:58 GMT+01:00 'Jasper N. Brouwer' via doctrine-user < > [email protected]>: > >> When using annotations, the classes and traits are merely the medium in >> which the mappings are defined. >> When using XML, YAML, etc, the mapping definitions are completely >> decoupled from code. So referring to a trait doesn't make a lot of sense to >> me. >> >> But I agree that some sort of "import" or "extend" logic in XML, YAML, >> etc would be nice! >> >> PS: "import" is already supported by Symfony2's config / YAML parser (not >> sure in which of these 2 it's located). >> > > Actually I thought more of a "inherit" than an "import"/"include", because > latter one impliesy, that the imported file is a kind of fragment, instead > of a full qualified entity-xml/yml-document, which imo would be quite ugly. > With "inherit" I meant, that the source could be like > > <entity class="Trait"> > <id name="id" /> > </entity> > <entity class="ConcreteClass"> > <field name="foo" /> > </entity> > > and "inherit" would copy all elements within "<entity>" of the given > class. As a side effect (as seen above) it would also allow to copy the > mappings from other real, or abstract entities too, similar to > "mappedSuperclass", but without the need to actual let the entity inherit > from the other class. > > > While typing, TL;DR: I thought of it as "copy elements from X" :) > > >> >> -- >> Jasper N. Brouwer >> (@jaspernbrouwer) >> >> >> On 25 November 2014 at 22:20:23, Sebastian Krebs ([email protected]) >> wrote: >> > > This is logical given the way traits are working in PHP. They are >> > > compiler-based copy/paste. They don't exist during the runtime of the >> > > class. The reason why annotations can be defined in an handy way for >> traits >> > > is because they are copy/pasted too (but the loading is actually done >> for >> > > the class, not for the trait) >> > >> > Makes sense .... Maybe something like an import would be useful? >> > >> > <entity> >> > <inherit class="TraitName" /> >> > </entity> >> > >> > I don't know, if that's even possible. >> >> >> -- >> 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/d/optout. >> > > > > -- > github.com/KingCrunch > > -- > 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/d/optout. > -- 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/d/optout.
