[Iowa-general] Iowa + CSS / XSL?
khaines at enigo.com
Sun Oct 3 10:52:14 EDT 2004
On Sun, 03 Oct 2004 12:21:22 +0200, Daniel Cremer wrote
> My impression of XSLT from reading other's experience was that it added
> a big layer of complexity. If I remember correctly I remember reading
> someones blog saying they ditched it all and just used ruby for those
> needs. If only I could remember whose blog and which needs :).
> If you wanted to generate various types documents from XML using the
> ease of IOWA it would definitely be interesting to see what
> functionality could be transposed from the approaches you mention. I
> don't know if you are aiming to simply get the same functionality or
> also doing it in a standards way ?
XSLT can be a huge pain in the ass, but it can also be powerful. Dave
Thomas writes his books using an XML markup that he and Andrew Hunt
created. It's simple and easy to use. However, with a few tools it can be
transformed into HTML or into LaTex that in turn becomes a PDF of a book.
It is neat.
I think, if I am understanding, that the curiosity is on how one could tie
IOWA with FOA in such a way that one could author content in XML and then
for a web based presentation of that content, have IOWA automatically do the
> As far as I understand IOWA is designed much more to modify a
> template rather than reading in a document and spitting out a whole
> new one. This means that making a PDF, LATEX generator or some other
> file format that's not of XML/HTML sort would require big changes
> with a different approach in mind. I believe that adapting IOWA to
> allow this behaviour in "standard ways" could involve a huge amount
> of work, best approached at first as a separate project. However it
> raises interesting questions about how much document translation is
> possible in IOWA in general. Has anyone thought of pdf generation,
> or even creating CSS files dynamically ? I've never done that.
I'm going backwards here on your questions. Regarding dynamic CSS
generation, I sort of do that. I have a couple different static CSS files.
One is designed for IE's approach to CSS, and one is designed for browsers
that are standards compliant (everything else). I have a little component
that does a very simplistic check of the browser type requesting the file,
and if it smells like IE, it delivers the IE version of the CSS file.
Otherwise it delivers the other version. It's not quite dynamic CSS
creation, but it is dynamic CSS selection.
On the subject of using IOWA as a more general content engine, I talked with
someone about that last week. It's not really too difficult. The main
thing is that when dealing with something other than HTML, things like the
TR class that is triggered off of <tr oid=> syntax isn't very useful. What
IOWA needs to be able to do is to have one able to select which tag set(s)
one wants it to use. So if one wants to use IOWA to create documents using,
say, RedCloth instead of HTML, one tells it to use a different set of tags
to provide the dynamic capabilities in RedCloth syntax instead of HTML
The idea also is that if someone decides, for example, that there needs to
be a dynamic handling of frame related tags, and that doesn't exist in the
IOWA distribution, one can just write a few classes for Frame, FrameSet,
etc..., supply them to one's IOWA app, and then use them. Just as simply,
if someone is working with XUL for generating GUIs, one could provide to
IOWA a set of classes that provide repeats and dynamic stuff for XUL syntax.
That would let one easily craft templates in things other than HTML.
On the other hand, if IOWA is just a processing and deliver platform for
content that comes from someplace else, nothing really need be done at all,
as the CSS example shows. One can pull content in from anyplace, transform
it via Ruby however one wants, and then output it.
I've thought about using this to do on-demand generation of customized
email, for example. The email generator runs at some URL as an IOWA app.
The web server, in this case, is simply an interface through which one talks
to the email generator.
When something happens that requires a customized email be generated, the
code just hits the URL and passes whatever info the generator needs as query
args. The generator runs and returns, instead of HTML, a properly composed
email that can be piped straight to one's SMTP server or straight into
sendmail or whatever.
Likewise, one could use the same sort of structure to do on demand
generation of customized PDFs. Imagine an investment firm that wants to
provide secure, nicely formatted for printing statements of a person's
investments online. They want to include all sorts of graphs and charts of
performance and returns and so on. Well, one could setup a generator
through IOWA that would query the data from the internal data sources, and
then generate an encrypted PDF, on demand. The customer just clicks on a
link and gets back a PDF encrypted with the same password that they use to
login to the web site in the first place. When they open it, it's all their
information about their specific investments.
IOWA and the webserver just becomes the platform that provides an interface
to trigger and deliver the customized generation. That can all be done now,
with no changes or additions to the code.
More information about the Iowa-general