eZ Issues Tracker a écrit :
http://issues.ez.no/IssueView.php?Id=13080&ProjectId=1&Anchor=Comment257031
> Comment #257031 has been added by Derick Rethans.
>
> --------------------------------------------------------------------------
> Content:
> --------------------------------------------------------------------------
> Okay, I checked this now, and it is not a bug. It's meant to work like
> this. However, the documentation for the
> ezcTreeDataStore::fetchDataForNode method (and others) should be fixed to
> include that you only can set ->data once, with the explanation on how
> dataFetched and dataStored are working.
>
Well, if you say the API was meant to work like that, I can agree that
the bug has to be closed as wontfix.
Otoh it is hard for me to appreciate an API where a method call can be
used only once (or a property set) without wreaking havoc on the
underlying structure, and the only way to solve the problem is by
documenting this in the manual. It just does not feel right:
a - there is nothing in the name of the property that suggest this kind
of danger/limit
b - the fact that both the ezcTreeXml and ezcTreeXmlInternalDataStore
objects are in charge of not only reading but also writing the "fetched"
and "stored" properties (and taking action based on its value) violates
the most common data encapsulation assumptions. Plus it makes hard to
take advantage through subclassing of all the separation of concerns
that is, afaict, the main goal for the split of this functionality in
two separates classes
c - there is little added value in having a separate
xml-internal-data-store for subclassing anyway, since the relax-ng
definition is firmly set in the xml-tree class. If a data store can
decide on its own how the data is stored, it should be able to decide
the part of the spec that validates it (hint: by magic of namespaces, I
think this can be done. Use a different namespace for the "data" element
- hey, already done! -, and add to the ezcTreeXmlDataStore a function
that the tree will use during his constructor to fetch from it the
relevant relaxNG description. If this is not null, it is also used to
validate the xml)
d - the fact that the default data store that comes with the lib
contradicts the xml tree that is part of the same lib (the schema
defines data as optional, the store throws an exception if it does not
find it) is also quite strange. I would expect the two to be in close sync.
Having said that, I will just add as a personal note that there are out
there many APIs far worse than this one ;) I had just come to forget the
many reasons why I have never liked the php DOM apis, and while
examining the ezc tree code, I stumbled upon a couple of missing
features that made me want to cry: no direct way to select the children
nodes of a given node while limiting the research to avoid
grandchildrens, and no direct way to insert a node as first children of
the current node. The php api for array manipulation is soo much better!
Thnaks for taking the time for reading through this.
Gaetano
ps: I can file a feat. request for point C above. The feature request to
the php internals devs for a simpler dom api I will keep for another time...
pps: relax ng "interleaving" pattern can also be added to the rng spec
to allow for the data element to be present after the nodes, or even in
the middle of them. Maybe this would do, too:
<zeroOrMore>
<ref name="node"/>
</zeroOrMore>
<optional>
<element name="etd:data">
<text/>
</element>
</optional>
<zeroOrMore>
<ref name="node"/>
</zeroOrMore>
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
