Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: PDF::Template redesign - I want your ideas!

by stvn (Monsignor)
on Dec 01, 2005 at 20:33 UTC ( #513426=note: print w/replies, xml ) Need Help??

in reply to PDF::Template redesign - I want your ideas!

Keep the XML file structure, but do it smarter. I have no idea what smarter would be, but this is the only backwards-compatible solution.

Well, I assume by "smarter" you mean "more concise", which unfortunately is not that simple with XML (see HTML for an example of this problem ;). However, maybe if you were to follow the Ruby-on-Rails idea of "intelligent defaults" this might work. The problem of course is, what are those "intelligent defaults"? Taking this idea to an extreme, and you will end up with a PDFML of some kind, which might not be a bad thing.

Somehow, do a TT plugin that provides a bunch of helper functions. Doing this, your template would consist solely of TT directives, some of which would be provide by TT and the rest provided by this plugin. I like this idea, but don't have much of a plan to accomplish it.

I know nothing of TT plugins, but it sounds like what you really want to do is to re-use the TT parser and get some kind of AST (abstract syntax tree) which you can use to build your PDF from.

This idea has it's merit, especially since you get a high quality parser that has been thoroughly battle tested already. However, I question if a PDF-mini-language embedded in TT would not end up being almost the same as writing it using Pure Perl as your template language. And if given a choice between TT or Perl as my mini-language, I might lean towards Perl since it as much more robust. But then again, restricting functionality is sometimes a good thing too.

Overall, I am skeptical of this approach, I am not convienced it will buy you anything more than Pure Perl.

Do something else. I have no idea what "else" would be.

Well, you can write your own DSL (domain specific language) for PDF templating. Using something like Parse::YAPP or Parse::RecDescent is probably not all that much more difficult than making the XML "smarter" anyway. This would force others to learn your new language, but if you keep it "familiar", then it probably won't be any harder to learn than some esoteric XML dialect.

Whatever you choose, I would recommend creating a kind of Object Model for PDFs, similar to the HTML DOM (but not as complex and ugly). If done properly, this would serve as the "runtime" for your PDF templating language, and would allow for multiple "front-ends" to be written (XML, DSL, TT, etc). It would also be easy to exchange various "back-ends" as well (pdflib, PDF::API2, etc).

Anyway, thats my 2 cents (and an upvote).

  • Comment on Re: PDF::Template redesign - I want your ideas!

Replies are listed 'Best First'.
Re^2: PDF::Template redesign - I want your ideas!
by eric256 (Parson) on Dec 01, 2005 at 20:46 UTC

    If you stick with XML as the base template language, then couldn't you realy build a TT plugin that helps output that XML in an easier way? Then if you want real power you can go to the XML, but if you want ease you can use TT.

    $more_options > $less_options unless time_to_develop($more_options) > life_of(%universe)

    Eric Hodges $_='y==QAe=e?y==QG@>@?iy==QVq?f?=a@iG?=QQ=Q?9'; s/(.)/ord($1)-50/eigs;tr/6123457/- \/|\\\_\n/;print;

      One last thought from me. What about using some subset of DIVs from HTML so that HTML Editors could be used to generate PDF templates? I'm not sure I like that idea much, but using an existing layout scheme has advantages in the forms of existing editors, and disadvantages (like the fact that HTML sucks and we all know it ;) )

      Eric Hodges $_='y==QAe=e?y==QG@>@?iy==QVq?f?=a@iG?=QQ=Q?9'; s/(.)/ord($1)-50/eigs;tr/6123457/- \/|\\\_\n/;print;
        What about using some subset of DIVs from HTML so that HTML Editors could be used to generate PDF templates?

        Do you mean WYSIWYG HTML editors?

        The problem I see with this is that HTML DIVs are useless without CSS, which is where things get really messy. It is also worth mentioning that PDFs are very "page" centric, and those pages are of a constrained size, which doesn't match well with HTML and it's "take up as much space as needed" layout approach. Having written plenty of PDF "pagination" code, I know this can be trickier than it seems, and is not always easy to generalize.


      I considered this, however, I am not sure you gain anything more than the complexity you are introducing. It is basically using TT as a macro language for XML (which it already is). But how useful this might be to the user, I am not sure. However, in the depths of the "compiler" I could see using TT to do things like "unrolling loops" or something like that.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://513426]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (2)
As of 2021-10-20 19:30 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (81 votes). Check out past polls.