[plug] [OT] XSTL .vs. PHP .vs. ???

[Shayne O'Neill]

If xml transforms are done on the server side it all works well,
however... in all honesty its one of those technology that makes me think
"designed by a committee of electrical engineers who think they are
coders" ...or.... "something some asshole consultant will specify" (yes I
have "issues" with "consultants" :)

With the exception of a few loopholes (ie same xml source and some xsl
transforms to turn the same document into html, sgml and rss) it really is
just too much for most tasks. It locks up processor time in big tasks and
adds too much effort for small tasks.

easier to just get a nice simple templating system and generate it outa a
database

(heres a neato one... use python+pickles and feed it thru a string with a
bunch of %s 's etc)

Anyway. your mileage might differ.

------------------------------------
"Must not Sleep! Must warn others!"
-Aesop.
Shayne O'Neill. Indymedia. Fun.
http://www.perthimc.asn.au

On Fri, 4 Jun 2004, Sham Chukoury wrote:

> Tim, I doubt anyone can recommend whether you should use XSLT or PHP or
> something else, for your project. You haven't provided enough info with
> respect to 1) what 'interactive' means, in 'interactive zoo', 2) the
> kind of data transformations you're attempting to do, using
> XSLT/PHP/whatever, 3) what sort of 'dynamic' data your final production
> is likely to have (besides the animal/zoo data in XML files).
>
> Therefore, I can't tell you what you should use - I can only point you
> to information resources related to your query:
> - http://www.w3schools.com/xsl/xsl_languages.asp - Nice intro to XSL(T),
> with examples. Covers your questions about variables and xsl:if.
> - http://www.gingerall.com/charlie/ga/xml/p_sab.xml - Sablotron XSL
> processor (with support for PHP & Perl). Supports javascript, however
> this feature's not enabled in, for example, the Debian build.
>
> As for the separate XML files vs one big XML file issue, only you can
> make that decision, since you're designing the system. And yes, as Onno
> pointed out, you should design the overall system, before figuring out
> how to store data. (e.g. in your design, instead of mentioning XML file,
> XSL file, and XSLT processor, simply have things like 'data store',
> 'data processor', etc)
>
> IMO, XML + XSL can be rather convenient, when handling data that needs
> to be mapped onto some other XML schema, or published as (X)HTML. (makes
> it easy to present various data through certain XSL templates, instead
> of generating lots and lots of static HTML files) Basic XSL itself is
> rather easy to grasp. However, *don't* use these data formats and tools
> for the wrong reasons! Always look for a solution as simple as the
> problem. :P
>
> Good luck
> §:)
>
> _______________________________________________
> PLUG discussion list: plug at plug.linux.org.au
> http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au
>