I have DOM angst

[ReGenesis0]

So, I'm workign with XML in PHP5.
I like it. I finally worked out the trick of doing xsl
transformation with libxslt. Load tree, make transformation, yay!

But I'm missing a middle step somewhere. Creating DOM trees from
variables in memory, or manipulating data in trees loaded in.
firstChild nextChild seems... awfully comborsome, and of limited use
unless you already know the structure of the DOM tree you're parsing.

Does the trick lie somewhere in DOM's awkward support of xPath? I
accept that I will be building functions (or more liekly classes) to
proctor my manipulations of these dom trees, but I just... I have yet
to figure our the TRICK of manipulatign them in some sane,
non-soul-destroying manner.

I suspect that I'm just looking at thigns sideways, and if someone
were to turn me around so I'm facing the problem right, everything
would call into place like an optical illusion. All the DOM examples I
read online seem to be just how do very baic 'create a list' sort of
stuff, or readign from simple trees, not multi-level nested stuff,
possibly with the same tag-name appearign at different level of the
hierarchy.

POWER-DOM? Do such tutorials exist? Is there a book? I just
need... to know how to approach this.

-Derik

[Tony Marston]

I think you are trying to do too much with DOM. In my framework all screens
are built using XSL transformations, which means that I must have
intermediate XML files to hold all the data that is going to be used by the
XSL stylesheet. I never use XML files to manipulate data, just to hold the
data which is to be passed to an XSL stylesheet. Each XML document has to be
written to the structure expected by the stylesheet, and once it has been
transformed the XML document is discarded.

I do not use XML documents for persistent storage, they are transient -
created, processed, discarded.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

<Re********@aol.comwrote in message
news:11**********************@74g2000cwt.googlegro ups.com...

So, I'm workign with XML in PHP5.
I like it. I finally worked out the trick of doing xsl
transformation with libxslt. Load tree, make transformation, yay!

But I'm missing a middle step somewhere. Creating DOM trees from
variables in memory, or manipulating data in trees loaded in.
firstChild nextChild seems... awfully comborsome, and of limited use
unless you already know the structure of the DOM tree you're parsing.

Does the trick lie somewhere in DOM's awkward support of xPath? I
accept that I will be building functions (or more liekly classes) to
proctor my manipulations of these dom trees, but I just... I have yet
to figure our the TRICK of manipulatign them in some sane,
non-soul-destroying manner.

I suspect that I'm just looking at thigns sideways, and if someone
were to turn me around so I'm facing the problem right, everything
would call into place like an optical illusion. All the DOM examples I
read online seem to be just how do very baic 'create a list' sort of
stuff, or readign from simple trees, not multi-level nested stuff,
possibly with the same tag-name appearign at different level of the
hierarchy.

POWER-DOM? Do such tutorials exist? Is there a book? I just
need... to know how to approach this.

-Derik

[universalbitmapper]

Re********@aol.com wrote:

So, I'm workign with XML in PHP5.
I like it. I finally worked out the trick of doing xsl
transformation with libxslt. Load tree, make transformation, yay!

But I'm missing a middle step somewhere. Creating DOM trees from
variables in memory, or manipulating data in trees loaded in.
firstChild nextChild seems... awfully comborsome, and of limited use
unless you already know the structure of the DOM tree you're parsing.

Does the trick lie somewhere in DOM's awkward support of xPath? I
accept that I will be building functions (or more liekly classes) to
proctor my manipulations of these dom trees, but I just... I have yet
to figure our the TRICK of manipulatign them in some sane,
non-soul-destroying manner.

I suspect that I'm just looking at thigns sideways, and if someone
were to turn me around so I'm facing the problem right, everything
would call into place like an optical illusion. All the DOM examples I
read online seem to be just how do very baic 'create a list' sort of
stuff, or readign from simple trees, not multi-level nested stuff,
possibly with the same tag-name appearign at different level of the
hierarchy.

POWER-DOM? Do such tutorials exist? Is there a book? I just
need... to know how to approach this.

-Derik

Hi, I'm a newbie in PHP/XML, but I found this book:
ISBN 9 780975 240205
by Thomas Myer, No nonsense XML Web development, Sitepoint.
They have a forum, you might be better asking your question there.

http://www.sitepoint.com/forums

XML is going to be very big from next year on with Vista and Office
2007.
And you're right to use DOM, HttpdRequest, that's the way to manage
the data flow and the presentation seamlessly :-)

[ReGenesis0]

Tony Marston wrote:

I think you are trying to do too much with DOM. In my framework all screens
are built using XSL transformations, which means that I must have
intermediate XML files to hold all the data that is going to be used by the
XSL stylesheet. I never use XML files to manipulate data, just to hold the
data which is to be passed to an XSL stylesheet. Each XML document has to be
written to the structure expected by the stylesheet, and once it has been
transformed the XML document is discarded.

I do not use XML documents for persistent storage, they are transient -
created, processed, discarded.

So how do you create your transient XML files from data?

I just... XML is suppsoed to be the universal interchange format
for data. (Whether you believe it's particularly good for that is up
to you I guess) Why... REDUCE it to just an intermediate step for xsl
transformations? Why not just send your data as variables to Smarty or
something? (I guess, you want the power of the xsl:template
includes... but not give up the querying speed of a sql database, which
is valid.)

...I don't want that power. ;-) (Or rather I want something else
specific.) I don't want to REDUCE XML to an itnermediate step in
templating. There are tools for manipulating it in trees, therefore
it's possible, just the actual application is escaping me.
I guess, I don't find "but it's AWKWARD" to be an adequare answer
here. There's a dom, and tools for manipulating XML. But you can't
manipulate XML?
Perhaps I'd have more luck on an XML newsgroup, despite my question
being PHP-specific.

-Derik

[Tony Marston]

<Re********@aol.comwrote in message
news:11********************@e3g2000cwe.googlegroup s.com...

Tony Marston wrote:

>I think you are trying to do too much with DOM. In my framework all
screens
are built using XSL transformations, which means that I must have
intermediate XML files to hold all the data that is going to be used by
the
XSL stylesheet. I never use XML files to manipulate data, just to hold
the
data which is to be passed to an XSL stylesheet. Each XML document has to
be
written to the structure expected by the stylesheet, and once it has been
transformed the XML document is discarded.

I do not use XML documents for persistent storage, they are transient -
created, processed, discarded.

So how do you create your transient XML files from data?

See http://www.tonymarston.co.uk/php-mysql/domxml.html for PHP 4
See http://www.tonymarston.co.uk/php-mysql/dom.html for PHP 5

I just... XML is suppsoed to be the universal interchange format
for data. (Whether you believe it's particularly good for that is up
to you I guess) Why... REDUCE it to just an intermediate step for xsl
transformations?

Because I don't *need* XML for anything else.

Why not just send your data as variables to Smarty or
something?

Beacuse I don't know Smarty but I do know XSL.

(I guess, you want the power of the xsl:template
includes... but not give up the querying speed of a sql database, which
is valid.)

As you said yourself, XML is an *interchange format* not a *persistent
storage format*.

...I don't want that power. ;-) (Or rather I want something else
specific.) I don't want to REDUCE XML to an itnermediate step in
templating. There are tools for manipulating it in trees, therefore
it's possible, just the actual application is escaping me.
I guess, I don't find "but it's AWKWARD" to be an adequare answer
here. There's a dom, and tools for manipulating XML. But you can't
manipulate XML?

The tools for manipulating XML are supposed to be better in PHP 5 than PHP
4, but the whole pointof XML is *not* to be manipulated, simply written by
one process and read by another process. It is used to exchange data between
different processes, not to provide a storage mechanism as a replacement to
an SQL database.

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org

[ReGenesis0]

Tony Marston wrote:

The tools for manipulating XML are supposed to be better in PHP 5 than PHP
4, but the whole pointof XML is *not* to be manipulated, simply written by
one process and read by another process. It is used to exchange data between
different processes, not to provide a storage mechanism as a replacement to
an SQL database.

See, I'd be a crumudgen and say- "The point of XML is to store your
date IN and XML string in a field in a sql database. Certain key
values like a date and ID will remain as seperate db-fields, but for
the MSOT part, it's a lump of xml code."
The advantage here, if you want to change the type of date you're
storing, or if the type just varies a lot, (say if you have 16
different types of content_types all with different sub-fields you want
to sore in the same database) You dont' have to go back and re-work
your databse queries. It's a standard query. "Go and get the xml code
nugget, chuck it bodily at a xsl sheet. The XSL stylesheet will treat
it appropriately based on the content_type attribute in the base tag."

Searchability/queryabnility goes all the hell udner this system, but
flexability and expandability goes way, way up. It's inappropriate for
some applications, but very appropriae for many others.
But, this presupposes the ability to manipulate complicated nested xml
files, (largely from a form handling standpoint.)

(Storing XML in a text field sounds back-assward, but I've seen this
basis system in action on a proprietary internal system, it works very,
very well, and I WANT that level of flexability.)

Some meditation on the issues involved has me thinkign that basically
what I need is a simpler way of manipulating things in memory.

I'd been avoiding simpleXML in favor od DOM-based solutions on the
premsie that DOM is the better/'correct' way of doign things, but the
more I look, it seems like the itneroperability of dom/simpleXML simly
BEGS for me to manipulate thing in simplexml, and then just conver them
back for xsl interpretation.
(I'd been thinking of simple XML as a seperate 'dumbed-down'
implemantation, but it starting to look more sideways of DOM, liek
theyr'e seperate tools meant to be used together for their strengths.)

IS SimpleXML what I'm looking for? (Basically, I'm giving you an
opportunity to say something bad about it.)

-Derik

[Tony Marston]

I don't need to manipulate the contents of XML files so I cannot give advice
on the best tool to use. I can only repeat that if you want to change data
at all then XML is not the best format by a long chalk. That is what
relational databases are for. XML is a data *interchange* format, not a data
*storage* format, certainly not for data that is liable to be modified. You
can store XML fragments in your database if you like, but if you want to
manipulate the contents of any of those fragments you will not find it a
easy as modifying an ordinary database table.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

<Re********@aol.comwrote in message
news:11**********************@i3g2000cwc.googlegro ups.com...

Tony Marston wrote:

>The tools for manipulating XML are supposed to be better in PHP 5 than
PHP
4, but the whole pointof XML is *not* to be manipulated, simply written
by
one process and read by another process. It is used to exchange data
between
different processes, not to provide a storage mechanism as a replacement
to
an SQL database.

See, I'd be a crumudgen and say- "The point of XML is to store your
date IN and XML string in a field in a sql database. Certain key
values like a date and ID will remain as seperate db-fields, but for
the MSOT part, it's a lump of xml code."
The advantage here, if you want to change the type of date you're
storing, or if the type just varies a lot, (say if you have 16
different types of content_types all with different sub-fields you want
to sore in the same database) You dont' have to go back and re-work
your databse queries. It's a standard query. "Go and get the xml code
nugget, chuck it bodily at a xsl sheet. The XSL stylesheet will treat
it appropriately based on the content_type attribute in the base tag."

Searchability/queryabnility goes all the hell udner this system, but
flexability and expandability goes way, way up. It's inappropriate for
some applications, but very appropriae for many others.
But, this presupposes the ability to manipulate complicated nested xml
files, (largely from a form handling standpoint.)

(Storing XML in a text field sounds back-assward, but I've seen this
basis system in action on a proprietary internal system, it works very,
very well, and I WANT that level of flexability.)

Some meditation on the issues involved has me thinkign that basically
what I need is a simpler way of manipulating things in memory.

I'd been avoiding simpleXML in favor od DOM-based solutions on the
premsie that DOM is the better/'correct' way of doign things, but the
more I look, it seems like the itneroperability of dom/simpleXML simly
BEGS for me to manipulate thing in simplexml, and then just conver them
back for xsl interpretation.
(I'd been thinking of simple XML as a seperate 'dumbed-down'
implemantation, but it starting to look more sideways of DOM, liek
theyr'e seperate tools meant to be used together for their strengths.)

IS SimpleXML what I'm looking for? (Basically, I'm giving you an
opportunity to say something bad about it.)

-Derik