Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
CSS       Right, it wouldn't lose much for the discussion even should the CSS not included. It's just more complete as an example with one.

STATIC XML       The static XML file is for the Artist (or Web/Frontend Designer) to be able to do the HTML markup with XSL without the Perl script even ready.

The static XML also serves as a req spec doc. In a working app, you probably won't have or need a static XML file sitting around. The XML will be generated dynamically from within a Perl script by then. But during the devel proc, it's good to have a static XML file against which to check your Perl's generated XML.

BOSS       Sorry for not explaining the BOSS-XML part. A BOSS could be your Project Manager or System Analyst or Team Leader. Or, to read that relation another way, a BOSS-Client conveyed a req to your Project Manager to your Lead Programmer who came up with the XML.

No, a non-techie BOSS handling XML won't be a good idea.

HTML::Template       Template is really a clean solution. Easy to use. It does the job of separating Perl and HTML. Especially nice when the same person who does both the HTML and the Perl. Not to hard for less technical Web designer to handle a Template either.

However, sometimes (or most of the times) a Template need to wait for a Perl script in order to see the complete HTML result. Hence, lacks the independency. XSL can check it against a static XML, not Perl script.

Also, when changes were made to both Template and Perl script simultaneously and something went wrong, you might need to check a Template and a Perl script against each other--an a bit more troublesome debugging process--whereas (in theory) XSL and Perl script check against XML (which is supposed to be locked/frozen).

Yet another situation, you need output to multiple media. A common req is that a client wants a report to be on the Web, as well as on PDF. (Well, refer to your phone bill, for example.) XSL makes a sensible solution, though I won't claim it's the best.

One more thing, you can't swap your "backend" (the Perl script) with Template. XSL doesn't care what backend you use.

Of course, if those are not your concerns, HTML::Template makes a good choice.

XML/XSLT NOT FUN       I must say, XML does require more discipline than many Web development companies are willing to commit to. (Many organizations tried to come up with some XML templates and ended up nowhere.) No, XML/XSLT isn't fun. Neither is trying to make a "quick fix" to a live system, just because some client/account manager forgot some "minor" req.

The point is not so much about using XML as it's about thinking things through. It's a mixed blessing that you don't need much planning to code a PHP page, for instance. XML forces you to do a bit more thinking.

A FOOTNOTE       Actually, to be more correct or "orthodox," when I said checking a Perl script's XML result against XML, I probably should or could have said DTD or Schema, in lieu of XML. But not everyone bothers with DTD or Schema. XML alone is an enough start.

In reply to Re: (jeffa) Re: XSL/XML/Perl as a development process by chunlou
in thread <strike>XSL/XML/Perl as a development process</strike> by chunlou

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (4)
As of 2024-03-29 08:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found