1. With SQL and HTML
2. Biometrics, though nametags help, if you can convince them to wear them
3. Following the XHTML specification
4. Figure out what you need to change, then ask the database to change it
5. Preface all of your SQL with "*- mother may i -*"

The moral of the story: there is more than one way to do things because there is more than one thing to do. You either live with that ambiguity, or you spend the rest of your life trying to fit every problem to your ONE BEST solution.

Update: ... and that's why exploring other languages, paradigms (functional, imperative), and even design techniques (UML, design patterns, use cases) is important.

What is the ONE BEST way to query a database table and display it as a web page?
What is the ONE BEST way to identify a user?
What is the ONE BEST way to create a web page?
What is the ONE BEST way to edit a database record?
What is the ONE BEST way to query a database?

There is no best way for any of these.

Differences in hardware (CPU model) is a start , as some software isn't available for all builds as of yet. Then you need to think about the OS and/or distribution vendor, as some tools work better on some CPUs than others. Then you need to worry about versions of those installed tools. What may be a great solution in a 1.0 version may be the worst solution in a 1.1 version due to changes in the tool backends.

Then you have differences in policy that might be set at the upper levels. Maybe you need to develop a solution that works with all other developers, thus limiting tools that might be guru's dreams that are also newbie's nightmares. Maybe you have to use very specific tools that are set by company security or policy, such as a specific version of perl or modules as have been cleared by an IT auditing team. And of course there is the structure of the team that is designing the program; does code separation from display have to be done to allow the graphic artists a stab?

And then there's personal preference. If monk A used tool Y for years, and monk B used tool Z (that does the same thing as Y) for years, there's no way that A and B will concur on the best tool.

In other words, we cannot even begin to recommend the BEST way to do something. We can say which solutions are *stupid* (such as reinventing CGI.pm), and we can offer *numerous* possible solutions, but it's up to the asker to evaluate those solutions and decide which is the best way in the asker's environment to proceed.

Computer programming is another form of engineering. There is no right or wrong answers. A good engineer knows how to think about all the possible solutions and evalute the one that works best.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Dear Fellow Monks, From your responses is time for me to be alot more humble! I therefor put my foot in my mouth, and admit what I really want to ask is :

Dear fellow perlmonks,

I am cosidering putting a couple of queries and table edits on our corporate intranet web page and would like to use apache/perl and DBI DBD::Sybase running on solaris or debian.

I am confused by all of the competing Modules that offer variying degrees of flexability. I am lost at the multitude of choices.

Has anyone any experience with any or all of them? can the perlmonks recommend anyone of them?

The real question is for me, what is the best place to start building a simple query application where I can reuse all of these nice html tools and still have a place to grow into?

A query builder like MSAccess with a datatable is what I am thinking about, or even a HTML isql window....

Yours truly,

mIke

• DBIx::CGITables
• DBIx::Abstract
• DBIx::XHTML_Table
• Apache::iNcom
• There is this maccess tool : http://www.meopta.com/products/software/maccess/
• My Site Maker http://www.itlab.musc.edu/mySiteMaker/
• Future SQL http://worldcommunity.com/opensource/futuresql/

Now this is a real question, and it should be in Seekers of Perl Wisdom. However, here is a brief opinion:

None of the tools you mention here are widely used. That doesn't mean they stink, but it does mean they are either too new or not generally useful enough to have attracted many followers.

One friend of mine did try DBIx::Abstract, and liked it, but in general I think the most efficient way to build a simple query application is the most obvious: use CGI and DBI. SQL isn't hard, and I generally find it much easier to write it directly than to use any of the abstraction layers I've tried. CGI is dirt simple, and it's easy to add in templating if you want to, with a popular module like Template Toolkit or HTML::Template.

If these really seem too low-level to you, I would suggest you post your question in Seekers of Perl Wisdom, and phrase it along the lines of "What's a good high-level tool for quickly building simple database editing apps?"

When there is only ONE CHOICE for employment, we call that communism.

When there is only ONE CHOICE for politics, we call that fascism.

When there is only ONE CHOICE for software, we call that Microsoft.

Just a little food for thought...

Vague humor alert....

Real monks don't sweat the eXPerience points

Real monks eXPerience OS's that don't need to phone home to Mommy for permission to run.

Real monks buy processors from companies that give their contractors a real business eXPerience, instead of the legal shaft.

You are correct about the impact of the terrorist attacks and the evolving threat biohazard threat. However, no one knows when it's time. Plan for the future, but make sure you're prepared in case your plans are, um, preempted.

What is the ONE BEST way to query a database table and display it as a web page?

Why the one that best solves the problem at hand, of course. There are many possible approaches. Have you experimented with them?

What is the ONE BEST way to identify a user?

By that which make him unique in the given context. Oh, yes, SSL helps, too.

What is the ONE BEST way to create a web page?

By hand rolling it from scratch. Only then will you know precisely what's included and what may be making it slow to load. Of course, it helps to understand the basics first.

What is the ONE BEST way to edit a database record?

Local or remote? Using deprecated syntax or "gee whiz"? Using that which the experienced use or others?

What is the ONE BEST way to query a database?

Well, I find being polite helps. And gentlemanly. (You'd be surprised how sensitive many dbo's are about their age.) Oh, you want a slightly less than facetious answer? Fine: SQL--if you must have ONE WAY.

In the end, there can be more than one way to do it. IT may be slightly messy, but so is Perl. Such is life. Enjoy.

--f

Busy non-technical managers are constantly bombarded with corporate propaganda, and they see the argument that company X makes OS Y, which works well with application Z. If it's all the same company it must work better!

I've just convinced my managment team to go with a Linux/mySQL/Apache/mod_Perl/mod_PHP web solution, that I'll custom write for them. The arguments have not been technical at all, but it's been a case of using FUD against the original NT/MS-SQL/IIS/ASP model.

While there is no ONE way, at the same time we can't stand around pontificating TMTOWTDI, while the industry "ONE WAY" monsters flatten us. While we may have won the tecnhical arguments, MS et al still have the hearts and minds of most corporate managment teams.

Thus even though there is no one way, we must at least sing from the same hymn sheet, even if we are singing different things!

I don't know how to phrase this properly, but we have to project, as a user body, a united front with one corporate voice. Even though we do things differently we must strees our unity, that is to say that the more than one way is our one way!

Our detractors see "more than one way" as our great weakness, we have to win the management argument that this is our strength. We can't use tecnhological arguments, you should see their eyes glaze over, we have to win on the home territory of the enemy, we need to win in the board rooms of corporations, not the operations room.

My very humble 2p.

AJT has hit the nail on the head, I think that he has put things into context. The question is : are we all pulling in the same direction in a coherent way? With a set of recommended modules and ways of doing things this convincing work will become much easier. Mike

I still don't understand this. I've worked at a company where there was one way to do things. The CIO made lithographic announcements from on high. He was no Moses. One group of programmers was competing with Microsoft with an enterprise product, and they were forced to use the Microsoft product. So I have a bias against "ONE WAY" proponents.

You'll also notice I left that company a year and a half ago. Send money.

The point is, the kinds of people who think there is only one way to do things are going to do things that way. In the 70s, that was mainframe computing. In the 80s, some of them used LISP machines. In the 90s, lots of them hired MCSEs and used NT on servers. Others invested heavily in Java everywhere.

I'm not interested in working for a company that won't allow me to consider the alternatives and find the best option for the situation. (send money) I'm not really interested in evangelising those kinds of managers, either. You're welcome to try, but I haven't found them terribly receptive.

What is the ONE BEST way to query a database table and display it as a web page?

The Data::Table module:

use DBI;
use CGI ':standard';
use Data::Table;
use strict;

my $dbh = DBI->connect(...);
my $table = Data::Table::FromSQL(
             $dbh,
             "select * from mytable where myfield = ?",
             'whatever');
print header, start_html('Results'), $table->html;
[download]

What is the ONE BEST way to identify a user?

Prompt for a user name and authenticate with a passsword if necessary. Or if you just want to guess at a userid, then you can look at the contents of the variable $< (see perlvar).

What is the ONE BEST way to create a web page?

The vim text editor.

Oh, you mean from within a Perl program? You can still write raw HTML code in a Perl program.

Or you could use the CGI module as I did earlier. I'll admit that this is what I typically do for dynamic web pages.

I'll also admit that when I'm creating tables I'll use the Data::Table or HTML::Table modules.

What is the ONE BEST way to edit a database record?

Assuming that you can use SQL, use it. Preferably via a DBI-like module:

$dbh->do("update table set blah = 'foo' where flurb = 'fleem'");
[download]

What is the ONE BEST way to query a database?

This is one I refuse to touch. It depends on what you're doing with the results. Querying is always pretty easy. It's using the results that can be tricky...

buckaduck