On Dec 31, 2003, at 9:49 PM, Terrence Brannon wrote:
And have some DBIx::Declare-aware template-processing engine handle
page requests automagically such that adding new templates and/or SQL
code doesn't involve writing or maintaining a single line of Perl
code.
you seem very HTML::Template o
Aaron J.Mackey wrote:
All I want to do with DBIx::Declare is provide a mechanism to separate
the SQL into a separate file than the templates, so that the template
designer only has to write:
Hello #person.name#
And the (now reusable) SQL as:
name: person_name_by_id
provides: person.name
requ
Hi David,
All good points; I'll try to address them one by one.
On Dec 31, 2003, at 1:51 AM, David Manura wrote:
It seems, as least from the SYNOPSIS, that the module itself could
deduce the "type," "requires," and "provides" statements by analyzing
the corresponding SQL rather than have the p
Aaron,
I'm taking a look through some of the database modules you and Terrence
have mentioned, and I have a few first impressions of DBIx::Declare. It
seems, as least from the SYNOPSIS, that the module itself could deduce
the "type," "requires," and "provides" statements by analyzing the
corr
regarding "still requires your Perl code to know the names of your SQL
statements" ... if you take a look at your ABSTRACT example. The
process of getting the SQL and creating $dbx is missing.
The SQL can live in any format/object, as long as it somehow includes
sufficient provides/requires "me
On Dec 24, 2003, at 2:21 PM, Jay Hannah wrote:
Your email client line-wrapped the POD. Is there a URL for easier
reading?
Thanks, I've put it up at
http://www.people.virginia.edu/~ajm6q/dbix-declare.html
If interested, please comment on this module I'm currently developing:
NAME
DBIx::Declare - Interact with DBI-based storage via declarative
constructs
SYNOPSIS
use DBIx::Declare;
use DBI;
use YAML qw(Load);
my $dbh = DBI->connect($dsn, $user, $pass);
my $sql =
