Re: Using PHP to parse specific XML tag content?
- From: Jerry Stuckle <jstucklex@xxxxxxxxxxxxx>
- Date: Fri, 05 Dec 2008 08:36:01 -0500
Pavel Lepin wrote:
Jerry Stuckle <jstucklex@xxxxxxxxxxxxx> wrote in
<ghb2t1$vd2$1@xxxxxxxxxxxxxxxxxxx>:
Pavel Lepin wrote:Jerry Stuckle <jstucklex@xxxxxxxxxxxxx> wrote inThis is completely worthless when run from a Windows web
<gh9t0a$9lg$1@xxxxxxxxxxxxxxxxxxx>:
_Z_ wrote:That's not true. At the very least, libxslt and xsltprocOf course you have to have xsltproc installed, but IEven more basic that that - you have to have permission
assume you have it. This way enables you to test your
XML --> HTML transformation in testing environment. For
example: bash# xsltproc MyForm.xsl TestData.xml
to execute commands, which many shared hosts do not
allow.
And you must, of course, be running on a Linux system.
run just fine under Windows using Cygwin, and, unless I'm
much mistaken, the open source *BSD family. I suspect
there wouldn't be any problems running it on any
reasonably sane proprietary UN*X as well. libxml2 and its
evil twin libxslt seem to be among the most widely spread
libs in the world.
server. Running on a Windows server generally means you're
running IIS. Alternatively, you're running Apache native
under Windows.
Well, that's not exactly true either, I've seen about half a
dozen small Windows-based web-servers in the past few
years, and not a single one of them was running IIS, it was
always either native Apache, or Apache compiled under
Cygwin, BUT...
What - some guy running a server out of his basement? I'm talking about data centers with multiple T3 or fiber links, generator backup and people available 24/7.
How many of these data centers are going to spend the money to run Apache? They're going to be running Windows because their customers require something only Windows can offer - which almost always means IIS and other MS products.
And they aren't going to run cygwin on these systems, either. If they wanted Linux, they would install Linux. It's much cheaper (both to buy and manage).
Please tell me ONE Windows hosting company which has
cygwin installed and running on their system.
...this is a very good point. I seem to have lost the
context of third-party hoster offering Windows servers;
indeed, in that context libxslt/xsltproc is highly unlikely
to be present or even obtainable.
The same is true on shared hosts running Linux/Apache. Most do not allow exec() or system() calls and/or do not have the software installed.
For your suggestion to work,you would have to have either
a VPS or dedicated server - which is way too expensive for
a small site.
I'm paying about $200/year for a VDS. I suppose there are
some organisations that would find this cost prohibitive...
then again, if I were a hired software engineer for such an
organisation, I would gladly pay the fee out of my own
pocket for the simple luxury of having a fully configurable
environment at my disposal. :-)
That's about right. I'm paying about the same for each of my VDS's. But they also require much more management. You can add several thousands of dollars a year to pay someone to manage it for you. And if you do have someone on the staff who can manage it, you need to figure the other work that person can't do because he/she is managing the server.
And even then - your command won't work. You have to
first start the cygwin environment, then execute the
command. You may be able to do it from a system()
command, but I'm not positive.
Um, I might be wrong here, it's been some time since I last
tinkered with Cygwin, but I don't think this is correct.
Unless I'm much mistaken, there's no Cygwin environment per
se, the executable files are simply linked against the .dll
(cygwin1.dll or somesuch) providing a bridge between the
linuxy interfaces and native Windows APIs. Once you have
Cygwin properly set up, you can run xsltproc.exe from
cmd.exe just fine, without running anything else first.
Yes, there is a cygwin environment. As I said - you may be able to do it with the system() command, but I'm not sure.
That's likely beside the point in context of the OP's
problem, but I honestly believe that any business case
justifying anything but the most trivial XML processing can
also justify the costs of a decent VDS.
Very true.
Yes, but you have to learn XSLT or use whatever defaultsSorry, either that doesn't make sense or I'm missing yourThat is the end of the story if you want only toOnly if you have those tools installed, and can stand
display the data from XML file.
the default format produced.
point completely. There's no 'default format' if we're
talking about XSLT. It's a programming language designed
specifically for document transformation, so the 'default
format' is whatever you choose it to be.
are provided by the samples.
Learning XSLT is eminently worthwhile in my experience. :-)
And as I said - it's another language to learn and keep up with. That takes time. And time is money.
True, SimpleXML and DOM give a lot of control and areSure there is. For the points I mentioned above.
often the most reasonable choice for XML processing. But
there's absolutely no point in not having XSLT in your
toolbox. If you need transformations, it's often the most
cheap, efficient and maintainable approach.
I'm not saying XSLT isn't good. But it's something else
which must be installed on the host, which is not possible
in the vast majority of systems out there - because they
are on shared hosts.
Points acknowledged.
And even if the programs are installed, it's another
language to learn and keep up with.
I cannot fully agree with this if we're talking about
professional software engineers. DSLs such as SQL, regexen
and, yes, XSLT exist for extremely good reasons: the
paradigm shift allows to express certain classes of
algorithms far more clearly and concisely than it would be
possible in the hosting general-purpose language. As such,
I perceive 'another language to learn and keep up with' as
a Good Thing. It's no different from 'another API to learn
and keep up with', assuming the API in question allows you
to solve some class of problems with ease.
That's true. But it's also hard to keep up with all of those languages. I currently am doing VBScript (ASP), C/C++, PHP, JavaScript, SQL (with a couple of different databases) and a little Perl. As a result, my Java (which I used to know quite well) has gotten rusty. Not to mention my Fortran (which I've been doing for around 40 years) and a dozen other languages I've learned and used in the past.
Languages are good to know only as much as you can keep up with them and stay in practice. Sure, you can pick it up more easily than you learned it the first time, but there is a limit. And then you have to pay for the hosting to support it (i.e. a VDS or dedicated server).
DOM API might be somewhat easier to get the hang of than
XSLT, but it, too, is something one should learn and
understand before applying it as a solution to practical
problems.
True, but it's part of PHP, and supported by almost every hosting company. Those which don't support it are most often running an old version of PHP which isn't even supported any more. And I wouldn't host with such a company.
Again, not reasonable for someone who doesn't do it
regularly.
Well, yes, but amateurs running into something that's way
above their heads should either leave it to the
professionals or go pro themselves, shouldn't they?
Yes, but going pro doesn't mean you have to learn every language under the sun. There is a limit.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.
- Follow-Ups:
- References:
- Re: Using PHP to parse specific XML tag content?
- From: Jerry Stuckle
- Re: Using PHP to parse specific XML tag content?
- From: Pavel Lepin
- Re: Using PHP to parse specific XML tag content?
- Prev by Date: Re: Using PHP to parse specific XML tag content?
- Next by Date: Re: Regular expression problem
- Previous by thread: Re: Using PHP to parse specific XML tag content?
- Next by thread: Re: Using PHP to parse specific XML tag content?
- Index(es):
Relevant Pages
|
