[OT] ISO book on CGI design

K

kj

For some reason that I can't quite figure out, my CGI projects are
far less readable and maintainable than the rest of my coding
projects. I've developed several awful, unmaintainable,
for-internal-use-only CGI projects (using Perl, CGI.pm, and JavaScript
exclusively) over the last 4 years now, and it's about time I
learned to do it right.

I'm looking for a book on good CGI design and best-practices. If
the book is Perl-oriented, then all the better. Your suggestions
would be much appreciated.

Thanks!

kj
 
E

Eric Schwartz

kj said:
For some reason that I can't quite figure out, my CGI projects are
far less readable and maintainable than the rest of my coding
projects. I've developed several awful, unmaintainable,
for-internal-use-only CGI projects (using Perl, CGI.pm, and JavaScript
exclusively) over the last 4 years now, and it's about time I
learned to do it right.

The #1 rule of All Time, when doing web-based apps, is:

1) Use templates to generate your HTML!

I don't care if you use Template Toolkit, Mason, Amrita (a very nifty
templating system in Ruby), or what, but if you use a templating
solution, you will be happy, and babies will smile when you walk by,
women will want to be you, men will want to be with you (or
vice-versa). If not, then it will be chaos and insanity! Dogs and
cats living together! Madness, I tell you, MADNESS!!!

I may have exaggerated slightly in the previous paragraph, but the
point remains: use templates. From there, almost everything else
seems to just fall into place.

-=Eric
 
J

John Bokma

kj said:
For some reason that I can't quite figure out, my CGI projects are
far less readable and maintainable than the rest of my coding
projects. I've developed several awful, unmaintainable,
for-internal-use-only CGI projects (using Perl, CGI.pm, and JavaScript
exclusively) over the last 4 years now, and it's about time I
learned to do it right.

What's the difference between those CGI projects and the other ones?
I'm looking for a book on good CGI design and best-practices. If

I don't know any of those. I know a lot of very bad ones though :-D
the book is Perl-oriented, then all the better. Your suggestions
would be much appreciated.

[1] Code clean, as with normal projects
[2] Use modules, and put common pieces in modules when required so
[3] Use a template system or similar for HTML (don't invent one)
[4] Use CVS or Subversion, log what you did, etc.
[5] Comments and maybe even POD.
 
K

kj

The #1 rule of All Time, when doing web-based apps, is:
1) Use templates to generate your HTML!
I don't care if you use Template Toolkit, Mason, Amrita (a very nifty
templating system in Ruby), or what, but if you use a templating
solution, you will be happy, and babies will smile when you walk by,
women will want to be you, men will want to be with you (or
vice-versa). If not, then it will be chaos and insanity! Dogs and
cats living together! Madness, I tell you, MADNESS!!!

Madness pretty much describes my code, and I agree that it has
something to do with generating all the HTML dynamically with
CGI.pm.

So the consensus (of 2) seems to be "templates". I'll look into
them.

(Any recommendations?)

kj
 
X

xhoster

kj said:
Madness pretty much describes my code, and I agree that it has
something to do with generating all the HTML dynamically with
CGI.pm.

So the consensus (of 2) seems to be "templates". I'll look into
them.

Yes, that does seem to be the consensus. Which makes me wonder--
I generate all my html with either CGI.pm or simple print statements, and
I haven't had encountered madness (well, not from this cause, anyway). But
I just use very spartan html forms and reports. What kind of madness am I
heading for? Are the problems averted by using templating system only
apparent in fancy-pants pages, or I have just been lucky so far?

Xho
 
S

Sherm Pendley

I just use very spartan html forms and reports. What kind of madness am I
heading for? Are the problems averted by using templating system only
apparent in fancy-pants pages, or I have just been lucky so far?

For smaller jobs where one person wears all the hats, it's not so critical -
at that point, it's mostly just an issue of learning good habits that will
be useful to you later on.

But, when the site grows larger and it comes time to split your work between
a designer and a programmer, and maybe a copy editor as well, then having a
clean separation between components is an absolute must.

A simplistic view of that situation might be that the copy editor and
designer do their jobs, then hand off the result to the developer to code
the HTML and logic. It rarely (if ever) works out like that. Once the
interactivity is added, design problems become apparent that weren't
obvious in the static prototype - and once the design problems are taken
care of, the copy needs to be modified to reflect them. Of course, the new
design and copy demands some changes in the back end...

And so it goes, back and forth, for days at a time - sometimes weeks or even
months. If you have three people, all trying to get their work done by
passing around and making changes to a single document, it's an exercise in
herding cats. It's *much* easier when each person has their own document to
work on.

sherm--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,020
Latest member
GenesisGai

Latest Threads

Top