[Melbourne-pm] Help - I barely speak Camel.

Mathew Robertson mathew.robertson at netratings.com.au
Tue Jul 25 16:29:50 PDT 2006

>> Returning from that API will be some debug, which I'd like to combine
>> with the information and print out to a HTML file for reporting.
> This sounds like a job for a templating module. Take a look at Template 
> Toolkit ...
>     http://www.template-toolkit.org/
>     http://search.cpan.org/~abw/Template-Toolkit-2.15/lib/Template.pm
> ... you want to abstract the markup generation from your code as early 
> as you can. If you find yourself printing out HTML from within Perl then 
> you should almost always be using some kind of templating solution.

Also there are a number of alternatives to Template-Toolkit, eg:

>> As I'm dealing with a number of different database engines, I figure
>> I'll do the initial data mining using those engine's tools, and start
>> the Perl code with pulling data from a CSV file.  This seems easier to
>> me than trying to get a DBI going for each engine and using Perl to
>> do the queries.
> If you can afford the time, I'd bite the bullet and try to get DBI 
> going. It will help keep all the stuff you are needing to do for this 
> job in one place. If you do decide to go the CSV route, don't try to 
> parse this yourself, see one of the Perl modules Text::CSV_XS (fast) or 
> Text::CSV_PP (slow) or better yet DBD::CSV and use the DBI to access 
> that gathered data. The latter option will allow you to move to direct 
> DBI access to your data more easily since the code will likely be very 
> similar.

Seconded - if you can connect directly to the database, then do so.
Using the DBI interface is far easier than people give it credit
for, since you have direct access to SQL (some of the data mining
tools dont give you access to the SQL).


More information about the Melbourne-pm mailing list