@Marco, why would this impose a security threat? As soon as a malicious user has access to the metadata, the shit has already hit the fan ;) @Sebastian, it might be possible to include fragments of XML documents instead of complete documents using XPointer <http://stackoverflow.com/questions/16563106/how-to-use-xpointer-with-xinclude-to-reference-elements>, also see the W3C docs <http://www.w3.org/TR/xinclude/#xml-included-items>. Not sure about the support PHP / SimpleXMLElement / DOMDocument has for this... @Sebastian, my feeling is this would allow better re-use of Entities amongst different projects. My feeling is that when the XML Driver supports it and the metadata "does not know" where it comes from, it should be feasible, since a Trait is a run-time copy-paste of code as well. Whether it would preferred to put energy into this... not sure, also see Benjamin's stance on Traits <http://www.whitewashing.de/2013/04/12/traits_are_static_access.html>.
Cheers On 26 November 2014 at 16:40, Sebastian Krebs <[email protected]> wrote: > > > 2014-11-26 15:42 GMT+01:00 Marco Pivetta <[email protected]>: > >> We won't go down the XInclude path, I think: too many security issues >> involved. >> > > A feature-related issue is, that (as said before) an XInclude (or any > other include mechanism) would include the entire document > > <entity class="Trait"> > <field name="id" /> > </entity> > > <entity class="Foo"> > <include src="whatever/Trait.xml" /> > </entity> > > Would result in > > <entity class="Foo"> > <entity class="Trait"> > <field name="id" /> > </entity> > </entity> > > Which is invalid, what means, that it needs an additional schema > (including xsd) covering the "entity template"-formate. To me it still > sounds more reasonable to have a mechanism to copy the content, because > > - XInclude you can only use, when _both_ are XMLs. If I want to copy the > fields from an entity/trait of a 3rd party bundle, that uses annotations, > it would fail > - It would allow to copy fields for from concrete entities and not just > traits. Whatever the use case may be > - One doesn't need to learn a new schema > > Or to sum it up: It would be much more flexible. > > > Maybe somebody can already tell me: Can I stop talking, because from the > architecture it is completely impossible, not wanted and anyway a > completely stupid idea? Or is that something, that somehow can make sense > and is implementable (even if it's hard)? > > > >> On Nov 26, 2014 11:53 AM, "Menno Holtkamp" <[email protected]> >> wrote: >> >>> 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. >>> >> -- >> 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.
