On Wed, 13 Sep 2006 13:50:27 -0400, Jonathan Vanasco wrote > On Sep 13, 2006, at 9:28 AM, Frank Wiles wrote: > > > What I typically recommend to people is that they use a template > > engine like Template-Toolkit.org. You simply pass it a Perl data > > structure and then you have all of the same transformation > > possibilities as XSLT ( at least as I understand it ). And if you > > ever need the data as XML, you simply create a template for > > that ( or pass a special option to your handlers to return XML, > > etc. ). > > I agree with everything said so far > Perl Data Structures > Templating Engines > only toss into XML if you really want to. otherwise why bother > with 2x the work? > > I go a step further... > > All of my packages return Perl data structures > The structures are then tossed into an *abstract* template class > That abstract class wraps several templating engines , and will > output to any of them on the fly. This way i can use Petal and > HTML:: templates with the same app. I just pass a different render > flag or set a variable/constant. > If you did that, you could just wrap something that will parse the > perl structure into XML (or write a template to do it in your > langauge of choice ) > > If you're wondering why I'm wrapping in an abstract class, here's > the top 5 reasons It makes me less 'locked into' a templating > engine I can trivially switch engines on some pages where there are > performance concerns ( Petal was killing me on a specific page > render... but HTML::Template redid it in a fraction of time ) It's > less code to change when I need to switch templating engines It's > less code to change when I want to switch templating engines I've > already switched templating engines before, it wasn't fun. > > All of the 'web frameworks' do it to offer users better choice. I > do it to keep my options open.
Yes, great, many thank's for all your advice and opinions. I have some experience with templates, but not much, but understand the basics with them and their use. However, there is one thing that concerns me:unit testing the web application along with the framework. I understand that this is slightly off topic now, but still an important thing in the context. I am completely impossible with remembering things, I need to test and verify each small step/progress I do in development. Therefore I need a framework/system to work with that allows also for unit testing, this so that I can test the output of methods before they reach the client/consumer. I have an idea that if I release this app, I'd like to deliver also the testsuite along with the system, so that I can tell the prospective client that "here's the suite, lets run and verify that all is good.". And in case of problem, I can just ask them to run it, and return the results, to find the source of eventual problems. Of course this can be done by verifying datastructures like lists and hashes, naturally, but I sort of fancy the XML output for this reason, as I could use XPath to do check the methods. ( Now, I don't really know if these thoughts are sane*S*S*S*S*. ). Yes right, okey so thank's again. I am happy with your help, but of course if you have thoughts on this you are most welcome to reply. Best Greger -- QxRSSReader v1.2.6a released (30-06-2006) PortScanner v1.2.2 ( 09-08-2006 ) http://www.gregerhaga.net/ There are no stupid questions, but there are stupid answers.
