[Iowa-general] Iowa + CSS / XSL?

[Kirk Haines]

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 
transformation?
 
> 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 
syntax.

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.


Thanks,

Kirk