One of my new apps may benefit by being usable on WAP enabled devices.

Do you really want to make a drastic change in your development mehtodology because "one" of your apps "may" benefit? And didn't WAP basically fail? I don't hear much about it these days.

If you want to make an application that can output PDF, or HTML, or XML, or WAP, or whatever else comes along, just write it using templates. Separate the logic parts of the application from the presentation, so that you can always pass the data into a new template and generate something else.

Very good point!

So, what you are saying is, that by using an appropriate template I can output HTML, or XML or whatever. I am not sure how PDF would be generated with templates, but I am certain somebody will tell me! What you are sying perrin is that I can generate XML and do whatever with it, rather than having to use XML internally. Of course even a 'simple' templating package like HTML::Template should produce output in other markup styles dependant purely on the template itself.

Well, yes, WAP or whatever. When I had anything to do with cell-phones and the like I was designing the hardware, you know RF stuff and the like, not the firmware :) I am going to have to do a bit of a refresher on those pesky things. It is not just "one app" as such. It is a suite of tools which will include a scheduler for sales-people. The customers actual words it would be useful for us if the sales people using the new internet capable phones, or devices such as the Blackberry from RIM could access their scheduler functions and the like.

As a programmer - logic and presentation have no part being mixed up with each other. This afternoon I whipped up a simple test app with several functions - in PM terms - nodelets. By using a couple of different templates and a couple of stylesheets I effectively had a very neat 're-skinnable' application. This is the degree of separation I am looking for. Thus this will obviously effect my choice of template systems for this is the degree of flexibility the client is wanting to pay for!

jdtoronto

PDFs are basically PostScript, and people have used Template Toolkit (and probably other things) to generate PostScript. Then you pass it through something like ps2pdf. I believe in some cases the relevant part pf PDF is plain text, so you can actually do it just like HTML.

If you ever find something that you can't generate simply with a template, you just need to change your application a little to support views being implemented in different ways, i.e. this view uses HTML::Template and this one uses PDF::Reuse.

To get your feet wet, start with a basic XHTML tutorial if you haven't already. This won't show you the real value of XML (it's pretty much just a somewhat stricter form of HTML), but it will be quick reading and will get you a basic feel for the syntax of XML. After that, if you want to understand the benefits of XML over other markup languages like HTML, you'll need to read up on XML namespaces, XSL, and possibly XSLT. If you're serious about applying it to WAP, you then may also need to dig into RDF (though this is somewhat stiffer materiel than the preceding). The same w3schools website has tutorials on most of these things too, and most of them are light enough that you can read one in an hour or three, depending on how quickly you read. There are also various other XML-related things that you may or may not care about, depending on what you're doing -- XPath, XPointer, XML Schema (err, Schemata), and so on and so forth. Don't worry about learning all of these up front; some of them you may not need for a while if ever. Just learn the basics (XML and namespaces) and whatever other bits you need for your particular application.

If all you want to see are examples of XML in action, check out Mozilla (which uses it for its XUL widget sets and themes) and OpenOffice (which uses it for its file formats, among other things -- very handy, as it makes it easy for other apps to work with the files). XML is not the solution to all problems, but it IS useful.

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

The reason your colleague said that the only way is to use XML, is that there is a WML (wireless Markup Language) defined. WML is a set of XML tags that is defined for wireless devices. The meaning of those tags, and how they shall be processed is well defined.

Regardless whether your colleague's comment is 100% acurate, following a well defined standard is generally a good practice. Your application in WML (XML) will be supported by lots of wireless devices from the day it is born with less effort on your side.

actually, XML is a markup language just as much as it is a data format language. an eXtensible Markup Language even. the tricky part is that XML has no semantics of its own. it is just syntax. this may have been what you were trying to say, but it wasn't clear to me.

the fact that you can markup a document with XML makes it fundamentally different from just a fancy version of CSV. i would even go so far as to say that XML's ability to be used for marking up documents is much more important than as a data format. if you're already exchanging data in CSV files, there isn't much of a case to be made for switching to XML. but if you are trying to exchange any kind of document there is likely to be a reasonable case for converting to an XML format.

anders pearson

The biggest downside I saw is the overhead. Instead of birth date taking 10 characters, 2003/10/07 it can take many more:

<DOB>
   <DBYear>2003</DBYear>
   <DBMonth>10</ DBMonth>
   <DBDay>07</ DBDay>
</DOB>
[download]

YMMV

The biggest downside I saw is the overhead. Instead of birth date taking 10 characters, 2003/10/07 it can take many more:

Disk space is cheap, and any more than a few XML files would compress extremely well. Even if the data isn't intended to be shared, then the advantage that the data is pretty easy to read might be enough of an advantage to use XML.

davis

It's not easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day.