Dynamic Web Page approach?

[gj2666]

I have been asked to create a web interface for an access database. It's a pretty simple set of forms to submit and retrieve records. No transactions or anything fancy. What is the current thinking about how to implement this kind of functionality? Mason, straight Perl, XML, something else? Favorite modules? This is one of those projects where the the requestor has basically not provided any requirements so I'm left to my own devices. Of course TIMTOWTDI but thought I'd take a survey of the prevailing wisdom.

I'm basically a intermediate perl coder. I've used enough modules to understand how to use them. Maybe a little weak on data structures, and DB I/O. Markup languages aren't a particular challenge conceptually, (syntax always kicks my butt) but I haven't done any web development with perl since 4.x. Maybe 20 years ago?

Thx, gj

[injunjoel]

Greetings,
Though I agree with dragonchild's comment above, here are a few modules to look into if you are sold on using perl.

• DBI - for talking to databases.
• DBD::ODBC - for talking to Access.
• CGI::Simple - for dealing with web requests and responses.
• HTML::Template - to make the HTML in your life easier.

And here are some tutorials you should be familiar with.

• perlman:perldsc - Perl Data Structures Cookbook.
• Tricks with DBI - DBI tutorial.
• HTML::Template Tutorial.


-InjunJoel

[bibliophile]

I'd add CGI::Application to that list... probably overkill for what the OP wants, but it is easy to exend an app when new requirements come in.

Mind you, I'm just figuring it out myself... but so far I'm really quite happy with it :-)
Here's a tutorial at perl.com.

[gj2666]

Thanks, I'll take a look at the tutorials to start with and think about getting mysql running on the linux box again. gj

[CountZero]

Catalyst might be a good choice to quickly have a web-interface to a database running.

DBI and DBD::ADO play nice with MS-databases.

[gj2666]

Thanks, this looks interesting as well. I'll have to dig into the documentation a little bit more to see if it's something I can grok. gj

[gloryhack]

I was asked to do something like this about seven years ago, and it turned out that the Access database was optional -- it was what the start-up company was using for their in-house data, but the web site didn't yet exist and there was no reason to specify windoze as the hosting platform. So, I eliminated the windoze requirement, convinced them to provide flatfile (TSV) dumps of their data, and stuffed the whole thing into MySQL on Linux with Apache.

Their web site uses CGI::FastTemplate as the templating engine with MySQL behind it. CGI::FastTemplate was chosen (by me) because the site was originally deployed in a shared web hosting environment and being relatively light it doesn't compete too much with other domains wanting their fair share of resources. Today the site is on its own server, but we're still using CGI::FastTemplate because it ain't broke.

If I had it to do over again, I might still use CGI::FastTemplate because the client company likes to pinch pennies by doing a lot of their own web site maintenance, and the steeper learning curve of the more powerful templating engines would probably knock them for a loop. This way, I keep a happy client. I'd never suggest that CGI::FastTemplate is the best solution for even a simple majority of applications, but the learning curve is relatively short and shallow, and in this case it's done exactly what's needed and everyone's happy.

[gj2666]

Thanks, this module appears to be well documented and at my level of comprehension. I'll take a closer look. gj

[dragonchild]

Use .NET, particularly VBA, on top of IIS. Not only will VBA have all the functions you need to handle this, but, since you're running on Win32, you might as well use IIS. And, you have a ton of prior art to work from.

As for LAMP, Apache suffers from problems on Win32, Perl doesn't talk to Access that well, and you're not using Linux or MySQL.

In other words, use the right tool for the job. In this case, Perl isn't it.

[Herkum]

I think a better question to ask was why was he looking at Perl? He said that he had not looked in Perl in a while and he had no constraints on how to implement it.

My question would be, are you trying Perl to learn something or do you just want find a tool to get the job down quickly?

Do you even have a Windows server to with? What platforms do you have access too?

[gj2666]

I use perl daily (Activestate 5.8 mostly) for a variety of system administration and configuration management tasks and I use it extensively in ClearQuest and ClearCase (stupid bad rational's perl's) to customize those application's behavior, generating reports and other tasks including some html reports, hooks, triggers.

Having done extracts from Access using perl to load ClearQuest database using the CQ API and WIN32::OLE it didn't seem far fetched to use Access as the database for this. My guess is that we could just as easily use mysql. I'm familiar with Access and it's a quick tool for prototyping the database so that's where I started.

Why perl? I'd like to continue to extend my perl skills (practice makes...er...well anyway...) and I use them whenever I can, I enjoy it. It is unlikely I'll ever be able to become a truly competent perl developer without continuing to exercise it. I'd also rather go with the devil...er..language I know rather than the language I don't know (ie. VB.NET).

I'm still trying to identify what the hosting platform is for this project. I personally have access to a linux box (RH9) at home and more XP boxes than are really necessary. This is a "extra-curricular" project aimed at satisfying a quarterly MBO objective vaguely titled "build the company" or something equally obscure. The company is small and young. A fair questions is do they know what they're doing? Why was this assigned to me? Because I was available and asked for it. If they had to pay a FTE for this it could be many months before they'd get the work done. gj

[jdrago_999]

I prefer Apache::ASP + HTML::FillInForm.

You get:
• Automatic Session handling (via MLDBM::Sync by default)
• Script_On(Start|End|Parse|Flush) events
• Session_On(Start|End) events
• Application_On(Start|End) events
• Emailed error reports (emails server errors right to your inbox - highly configurable)
• Simple upload handling ($Request->Upload(...))
• Friendly interface to the Apache server API
  • $Server->RegisterCleanup( sub {...} )
  • $Response->Redirect(...)
  • $Response->End
• print $str actually works
• Familiar <% %> and <%= %> syntax


I have used Apache::ASP on a variety of projects, both low- and high-traffic and I have to say it performs well enough. Energy Works and ETundra both run Apache::ASP. I have also written some large scale in-house applications on Apache::ASP that I cannot link to.

Having extended the base Apache::ASP code in several different ways (altered XMLSubs behavior, db-persisted sessions, MVC-enhanced URI mapping, etc) I can attest to the quality of the underlying code in Apache::ASP as well - it's easy to override what you need to override without running into encapsulation issues.

I give Josh Chamas (maintainer of Apache::ASP) an A+ on his work. Check out the Apache::ASP homepage at http://www.apache-asp.org/ for more information.