] Inspired by closing comments from the UBB thread.
Nachrichtentext:
All,
In his closing comments about UBB Kyle Dawkins made a statement that got me
wondering. He said there's SQL embedded all throughout the Perl everywhere
(who does this?! oh my god, are they on crack?). This comment got me
On Thu, 2 Aug 2001, Tim Bunce wrote:
I think DBIx::AnyDBD is a pretty good compromise.
Well, I worked with Matt on the project for which it was developed
(WebBoard for Unix) and I still felt like there was just way too much
stuff to deal with. Just too much SQL. I wanted a more abstract way
All,
In his closing comments about UBB Kyle Dawkins made a statement that got me
wondering. He said there's SQL embedded all throughout the Perl everywhere
(who does this?! oh my god, are they on crack?). This comment got me
wondering about alternatives to embedding SQL in to the code of a
I think a lot of people's approach, including mine, is to have OO Perl
modules for all database access. In my code (I use Mason), a web page
only gets its data through calls like this:
my $obj = NAIC::User-(DBH=$dbh, EMAIL='[EMAIL PROTECTED]');
$obj-load;
my $groups_list = $obj-groups();
That
Joe Breeden [mailto:[EMAIL PROTECTED]] wrote:
...
wondering about alternatives to embedding SQL in to the code
of a program.
...
It would be interesting to know how other people have solved
that problem.
One approach is to use something like Ima::DBI, which I'm currently toying
with.
All,
In his closing comments about UBB Kyle Dawkins made a statement that got me
wondering. He said there's SQL embedded all throughout the Perl everywhere
(who does this?! oh my god, are they on crack?). This comment got me
wondering about alternatives to embedding SQL in to the code of a
I think a lot of people's approach, including mine, is to have OO Perl
modules for all database access. In my code (I use Mason), a web page
only gets its data through calls like this:
my $obj = NAIC::User-(DBH=$dbh, EMAIL='[EMAIL PROTECTED]');
$obj-load;
my $groups_list = $obj-groups();
* Joe Breeden ([EMAIL PROTECTED]) [010801 10:25]:
All,
In his closing comments about UBB Kyle Dawkins made a statement that got me
wondering. He said there's SQL embedded all throughout the Perl everywhere
(who does this?! oh my god, are they on crack?). This comment got me
wondering about
I'd second the original question, I've always embedded the SQL (what's the
S for?) in the code, isn't that the point of the wonderful DBD::*
packages? As far as modularizing database calls, there are a couple
reasons I've had problems with that. I found the methods being rewritten
to handle
On Wednesday, August 01, 2001, Perrin Harkins wrote the
following about [OT] Inspired by closing comments from the UBB thread.
ph Having your SQL right next to where it's being used is convenient,
ph and a HERE doc makes it easy to read.
Agreed. IMHO, it also makes it easier to maintain months
not to mention the HTML embedded all throughout the perl (are they on
glue?)
What's the alternative there? Embed perl in the HTML?
You could do that (Text::Template), or you could use a tool like Template
Toolkit or HTML::Template. See
http://perl.apache.org/features/tmpl-cmp.html for a
I wasn't clear enough... My point was more six one way, half dozen the
other. For a public package, keeping dependancies down to a minimum is a
bonus, as well as keeping performance up by not having to pre-process html
looking for perl code. It can come down to a choice between
maintainability
Jay Jacobs wrote:
I don't see any glue-sniffing symptoms from choosing
embedded html in perl over embedded perl in html.
Unless, of course, you're the graphic artist and you've been tasked with
changing the look and
feel of the application using embedded perl (which you, as the graphics
Guys guys guys
Mixing HTML with Perl with SQL is bad and evil on every single possible
level. For those who don't know how to split apart your perl from your HTML
I suggest you read some of Perrin's recent posts. There are so many ways to
do it, I won't even bother with talking about them
As for SQL, I just wish people would expand their horizons a little and
start doing a bit of reading. There are so many different ways to avoid
embedding SQL in application code and I sincerely wish programmers would
THINK before just coding... it's what differentiates scripters from
On Wed, 1 Aug 2001, Kyle Dawkins wrote:
Mixing HTML with Perl with SQL is bad and evil on every single possible
level.
This bugged me... TMTOWTDI applies on so many levels.
The right way to do something is not always the technically best way
to do something. If you work in a large corporate
All (and Perrin)
If you wish to see one enlightened approach, please read this:
http://developer.apple.com/techpubs/webobjects/DiscoveringWO/EOFArchitecture
/index.html
as I said... *ONE* enlightened approach :-)
I think you'd find that EOF (the persistence framework in that example)
On Wednesday, August 1, 2001, at 09:27 AM, Kyle Dawkins wrote:
Fine, it's Apple (yuk). But it used to be *NeXT*
and it used to be *Obj-C*, both very very fine things indeed.
Hey now! Those are fighting words! :-)
OS X
Mach + FreeBSD
Project Builder + GCC (Including Objective-C) in
On Wednesday, August 1, 2001, at 10:01 AM, Jay Jacobs wrote:
On Wed, 1 Aug 2001, Kyle Dawkins wrote:
Mixing HTML with Perl with SQL is bad and evil on every single possible
level.
If however you work in a two person company where you have barely enough
time to go to the bathroom let alone
At 12:50 PM -0400 8/1/01, Perrin Harkins wrote:
It would really be nice if someone could write an overview of the O/R
mapping tools for Perl. I know Dave Rolsky was working on one, but it's a
big job and he's busy with Mason.
I agree. There was a bit of discussion on this topic on this list
Tom et al.
Mixing HTML with Perl with SQL is bad and evil on every single possible
level.
If however you work in a two person company where you have barely enough
time to go to the bathroom let alone think about creating your own
database abstraction layer for a custom application
Woooie!?!
I didn't expect the firestorm this post would generate. From what I hear
people are either embedding SQL or writing their own utility module to
essentially do something along the line of:
$s-StartDBI ( DSN = 'somedsn_pointer') ;
eval {
$s-SelectSQL ( NAME = 'sql_select',
On 01 Aug 2001 10:12:45 -0500, Joe Breeden wrote:
All,
In his closing comments about UBB Kyle Dawkins made a statement that got me
wondering. He said there's SQL embedded all throughout the Perl everywhere
(who does this?! oh my god, are they on crack?). This comment got me
wondering about
Jay Jacobs wrote:
I don't see any glue-sniffing symptoms from choosing
embedded html in perl over embedded perl in html.
Unless, of course, you're the graphic artist and you've been tasked
with changing the look and feel of the application using embedded
perl (which you, as the
On Wed, 1 Aug 2001, Ray Zimmerman wrote:
One of the tools that is not mentioned in Dave's write-up (probably
because it didn't exist then) is SPOPS, mentioned earlier in this
thread.
No, I just hadn't had a chance to get around to it yet. I really need to
finish that thing someday. Of
On Wed, 1 Aug 2001, Kyle Dawkins wrote:
I've taken a look at many of them (Tangram? a few others) and haven't been
impressed with any of them. I think part of the problem is that they're all
being developed in a bit of a vacuum. But let's capitalise on the interest
that this thread has
As for SQL, I just wish people would expand their horizons a little
and start doing a bit of reading. There are so many different ways
to avoid embedding SQL in application code and I sincerely wish
programmers would THINK before just coding... it's what
differentiates scripters from
My apologies for beating this dead horse...
I am just unable to get my point across at all today.
On Wed, 1 Aug 2001, Kyle Dawkins wrote:
Tom et al.
This is, in my opinion, circular logic. Perhaps the reason that you
barely have enough time to go to the bathroom is that you're
writing
http://axkit.org/docs/presentations/tpc2001/anydbd.axp
Is this basically a hash of SQL statements, indexed by DBD type? Or is
there something more that I'm missing? (I should have gone to your TPC
talk...)
PROTECTED]
Subject: Re: [OT] Inspired by closing comments from the UBB thread.
http://axkit.org/docs/presentations/tpc2001/anydbd.axp
Is this basically a hash of SQL statements, indexed by DBD
type? Or is
there something more that I'm missing? (I should have gone
to your TPC
talk...)
On 01 Aug 2001 14:29:10 -0400, Perrin Harkins wrote:
http://axkit.org/docs/presentations/tpc2001/anydbd.axp
Is this basically a hash of SQL statements, indexed by DBD type? Or is
there something more that I'm missing? (I should have gone to your TPC
talk...)
All AnyDBD does is create a
Since you asked, my opinion is that what you describe would not be
useful. Primarily for the reason pointed out already by a number of people
-- lack of flexibility. Most, if not all, database servers accept highly
customizable performance params to a query, and most even moderately
evolved
--
Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com)
-Original Message-
From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 01, 2001 4:15 PM
To: Joe Breeden
Cc: [EMAIL PROTECTED]
Subject: RE: [OT] Inspired by closing comments from the UBB
At 02:44 PM 8/1/2001 -0700, Jeffrey W. Baker wrote:
On Thu, 2 Aug 2001, Gunther Birznieks wrote:
When you've had your fill of wrestling over mySQL vs PostGres and stored
procs versus inline SQL (I know I have long ago)
You guys should definitely read the following:
Nicely put Nick. There's already a Structured Query Language,
And there's an easy to use abstraction called DBI up on CPAN.
Feel free to use in application code thusly:
my $statement = qq~
SELECT field1, field2
FROM table
WHERE id = ?
~;
my $ref;
my $sth =
On Wed, Aug 01, 2001 at 01:19:58PM -0500, Dave Rolsky wrote:
On Wed, 1 Aug 2001, Kyle Dawkins wrote:
I've taken a look at many of them (Tangram? a few others) and haven't been
impressed with any of them. I think part of the problem is that they're all
being developed in a bit of a
On Wed, Aug 01, 2001 at 05:29:10AM -0700, Daniel wrote:
Nicely put Nick. There's already a Structured Query Language,
And there's an easy to use abstraction called DBI up on CPAN.
Feel free to use in application code thusly:
my $statement = qq~
SELECT field1, field2
FROM
37 matches
Mail list logo
