Rebuttle to chromatics

[princepawn]

This node falls below the community's threshold of quality. You may see it by logging in.

[chipmunk]

princepawn,

It seems that your rebuttal has been written as somewhat of a personal attack ("...people inane enough to use a low-level database interface..." and "...you appear not to know..."). Unfortunately, this detracts from your argument. You may want to consider rewriting this rebuttal so that the focus is more on the merits of the modules. I think this would make your argument more convincing.

[princepawn]

seems that your rebuttal has been written as somewhat of a personal attack ("...people inane enough to use a low-level database interface..." and "...you appear not to know..."). Unfortunately, this detracts from your argument. You may want to consider rewriting this rebuttal so that the focus is more on the merits of the modules. I think this would make your argument more convincing

You are 100% correct. I am 100% wrong. And I thank you for this lesson. May I learn from it and not repeat my mistake created in a moment of flared anger.

[coreolyn]

Maybe I'm warped but I like holy wars when they do such in depth detail. What harm is done?

coreolyn

[DrZaius]

SQL is not perl code. Therefore, it should not be in your perl programs. I generally have an 'SQL' directory that I keep one query per .sql file.

Now, all my html is loaded via HTML::Template and all my SQL is in external files. I only look at perl when I edit a perl file.

Functions to generate html is very ugly and a nightmare to maintain. So is SQL. Queries are complex business and should probably be written by hand; how many abstractions layers have gotten joins right?

Write your query, send it straight to DBI and use DBI's utility methods to get the output into a sane structure.

The only exception to this rule is inserts; insert queries are never more complex than a multivalued insert. Inserts should be automatically done for you.

oye.

[princepawn]

SQL is not perl code. Therefore, it should not be in your perl programs. I generally have an 'SQL' directory that I keep one query per .sql file.

Amen.

Now, all my html is loaded via HTML::Template and all my SQL is in external files. I only look at perl when I edit a perl file.

Now here we have some asymmetry. HTML is not Perl code either. Nor is it necessarily non-complex. However, your means of abstracting the two differ. Could you provide us with some input as to why your approaches differ? I think such a post would be one of the first posts to explore and expound some basic means of Perl Software Engineering.

Functions to generate html is very ugly and a nightmare to maintain. So is SQL. Queries are complex business and should probably be written by hand; how many abstractions layers have gotten joins right?

Have you read the docs for DBIx::Recordset. It handles all sorts of joins. Further, what do you plan to do when you want to write those same applications in a database independent form? This is an important question and I want to hear your answer to it. I do have an alternative to Recordset. It is Class::Phrasebook::SQL

[DrZaius]

Actually, HTML::Template loads the html off the file system. You do something like:

my $t = HTML::Template->new(filename => $file);

And pass any dynamic elements in.

We have an inhouse module called SQL::Serialized which is basically an autoload method that takes the method name, attaches .sql to the file and tries to load the query out of a file with that name.

We have been toying with releasing it vs rewriting it to use Inline (Inline::SQL). Then, we could also do something like Inline::HTML::Template.

This probably sounds goofy, but there is one situation in which SQL::Serialized is a massive bitch: utility scrips; the support files (.sql's) either have to be in a hardcoded location or the current directory.

My idea was to take advantage of using __DATA__ blocks for storing queries so that we don't have to deal with sql files for that. Inline has support for this sort of thing.

But, as it stands, currently, queries look like this

my $dbh = DBI->connect;
my $sql = SQL::Serialized->new(directory => './sql');

my $sth = $dbh->prepare_cached($sql->big_query);
$sth->execute(@place_held);

My views come from the fact that if you change database, you are going to have to change your SQL anyway. Although, one person I know says that if you write all your sql against dbase or some silly, lowest common denominator, databse that isn't the case.

[Jouke]

Princepawn Please. Do me -and a lot of others- a favour and end this holy war. I --'d this posting because you have extensively fought this war here on perlmonks.
I've had it!

Jouke Visser, Perl 'Adept'

[tilly]

This topic was already covered. My opinions have not changed from what was one of my harshest posts to date. It may be harsh, but that really was, and remains, my gut reaction to your article. I believe chromatic had about the same reaction. For about the same reasons.

I don't know if you read This is not a flame. I hope you did. I put a lot of thought and energy into that post, and I sincerely wanted you to take it to heart.

[Tuna]

Ditto what Jouke had to say. Oh yeah, it's spelled

R-E-B-U-T-T-A-L

Update: Ok, to give this post less of a sarcastic tone, I'm going to throw my two cents in.

When you write an article for publication in a public domain, you invite the reader to learn from your article, as well as invite scrutiny and possibly disagreement with all or part of its content. Time to move on, I'd say.

[princepawn]

When you write an article for publication in a public domain, you invite the reader to learn from your article, as well as invite scrutiny and possibly disagreement with all or part of its content. Time to move on, I'd say.

I don't mind attacks or disagreement. I invite disagreement in conjunction with discussion.

And thank you for the spelling correction.

[koolade]

As you can see from this recent thread: Why use HTML instead of CGI? (codediscussion) it is much sounder to use functions and data structures which map to the structure of the target syntax than to do free-form text manipulation.

Where did you see that conclusion in the thread? It seemed to me that comments were split on the issue--no right and wrong was defined. If anything, more people seem to prefer using templates for HTML.

[Odud]

It's sad to see so much effort wasted in pointless arguments.