XML binding & persistence library
[email protected] (Ян Программист) Mon, 15 Mar 2010 12:46:04 +0200
| Newsgroups | php.pecl.dev,php.gsoc |
|---|---|
| Message-ID | <[email protected]> |
--001636c5b46779691d0481d49620
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
*Description:* object-oriented library for mapping XML file structure,
binding to PHP 5 class. Library would provide functionality for using XML
based entity descriptions, described in XML Schema, to perform data
manipulations(CRUD facility), and would use described entity relations for
persisting XML entries. Association and/or aggregation would represent O-O
abstractions for XML entity relations. For performing queries would be used
either on-the-fly or automatically generated translation of XML entity
properties, characteristics to XPath expressions, which can give a
performance boost for production (read: non-development) usage. Also should
be implemented functionality for building XML formatters from XML Schema,
which itself avoids a lot of script execution speed reduction for preparing
& splitting together XML tree data structures
*Main implementation reasons and usage opportunities*:
-
Most of XML structures represent complex entries, where both nested tags
and tag properties represent characteristics and behavior. This usually
results in escalation of complexity of XML interpretation rules, code wi=
ll
be more heavy. Additional development penalty is that often such rules a=
re
less similar against each other =96 amount of reusable code is very low.=
Also
data entries, related to entities with deeply nested relations, would
require manipulation of a group of files as a single transaction to prov=
ide
persistence; normally there is no way to reuse XPath queries in a way, t=
hat
is entry based
1.
I have motivation to go even farther: iterators would act as a fork,
moving back an forth (development stage) threw a set of tags and/or t=
ag
properties. Iterators can become reusable in different projects, for
different XML structures, simply changing naming convention
(read: the way
how the tag names, with respect to W3C qualified name features)
2. Can help a lot in translating XML binding code threw XPath
expressions (because of specific W3C specification rules, which
supposed to
query all matched entries by default). Even possible to force
relations in
generated XPath to speed up querying =96 a complex expression can
specify one
rules before another (for example, if specific ancestor in XML tree w=
ould
arrive less often then some tag property, it can be possible to menti=
on
ancestor requirement before property requirement =96 less line
count would be
iterated*)
-
You could use PHP 5 reflection and O-O features of PHP 5 to describe
classes. And after that you can simply generate required XML Schema. Awe=
some
for using non-DOM (read: SAX) libraries at production environment,
especially if there would be a mix of PHP 5 code and, say, Java code (by=
the
way =96 code generator can produce code for other languages, if necessar=
y).
Good for situations where you should develop some administration tools w=
ith
web interface in PHP 5, which would operate on Java software XML based
configuration files (for example, XML configuration file for Java messag=
e
broker)
-
Of course, the well known mixing of database mapping(ORM) and XML
mapping. Would be awesome if there would be an import of ORM classes to =
XML
related ones and vice versa =96 more flexible RDBMS table structure. Awe=
some
for complex storage manipulations (storing objects and/or their entities=
in
XML and RDBMS, without an performance penalty of forcing RDBMS to format=
XML
for you). And, probably the most awesome here =96 you can move data from=
XML
storage to RDBMS and vice versa for balancing load performance, especial=
ly
if data characteristics can vary a lot. Generation of performance tests =
can
be added if necessary
-
XML web site maps. Yea, those are often in XML. Also their CMS systems,
that can manage site structure threw XML. And because MVC frameworks are
most wide solution =96 the site map itself is referred (directly or not)=
to
controller class =96 action name pairs. As a result =96 it is hard to fo=
rget
about automatic testing, that is where PHPUnit can come up. Main idea =
=96 use
site map as a prototype for defining more complex mapping. Some kind of =
XML
tree with entities described (entries are referred to controller-index
pairs, remember), where entities described in a test feature driven mann=
er;
you can force your testing automation with a guaranty of covering necess=
ary
QA features, even connect QA software to development tools. Note: DOM
library would be used at background due to complexity of testing
configuration
-
And, of course, the famous RESTful Web services ;) At least can help in
data deduplication...
--001636c5b46779691d0481d49620--