Leo Lapworth wrote: > I see what your saying, but it'd be a lot of effort to use a different > templating system just for the sheer hell of it,
There's a better reason than the sheer hell of it - separation of concerns. If your modules are tied down to one particular template engine then it suggests that you haven't got a clear separation between application and presentation. If possible, put all the presentation independant code in one module, say SVG::Graph. Think of this as your model. It defines the data for a particular graph and should provide methods to access and/or manipulate the data. Then write a module which defines a sensible API for creating SVG::Graph objects. Say, SVG::Graph::Reader, SVG::Graph::Factory, SVG::Graph::Controller, or something like that. Then write another module which defines a sensible API for presenting SVG::Graph objects. SVG::Graph::Writer, SVG::Graph::Presenter or maybe SVG::Graph::View. Then subclass your controller and presenter modules accordingly. In other words, if you design your system so that any template engine (within reason) can be bolted on, then the chances are that you will have designed a clearly separated system that will be easier for you and other people to use and extend. You have separated the internal representation of the graph from any particular external representation. This is of course related to Design Pattern #0 (IPO): INPUT -> PROCESSING -> OUTPUT Pretty much every program ever written conforms to this design pattern. It should be one of the first things you think about when designing a software architecture. Obvious, I know, but often overlooked. A
