in reply to RFC: Proposed tutorial - simple login script using CGI::Application

I thank you for taking such effort to present this tutorial++. But I must I admit that I only skimmed over the code listings so I can't comment on the logic or syntax. This is not a code snippet which I can just simply get it and run it. Since this is a complete application, I'd like to rather see the actual application online to see how it works. So we know what to expect before trying. Especially you claim that:
it does work
I don't think using a large number of modules would be a problem because tutorials has levels of audience. We can say that this tutorial is aimed for intermediate users, not merely beginners.

I'd like also to point about the documentation you refer to. It's nice to tell that those docs are also available locally, because one isn't always connected to the Internet. I guess many intermediate users already know about this, but I'd considered it value added if you mention that users can access Apache docs via http://localhost/manual and MySQL docs, provided that it's installed properly by whatever Linux distro users use or installed manually, via1:

$ info mysql $ pinfo mysql

And about the line numbers.... You should know that codes in PerlMonks are meant for downloading so it can be run right away without any modification (additional step, even if you provide a nice snippet to remove them) on the text unrelated to the code logic or internal data. But, I also support the usage of line numbers in the tutorial code as guidance or reference of the explanation. In this case, it's good to provide other means to obtain the actual codes.

Each listing should start with their own number 1. And it's better for me as audience to see the explanations separated for each listing. So when you say, for example, "" as suggeted by eric256, I know for sure what's the context that particular saying in. In this case of this clear separation of the explanations, it's useful to make cross references by explicitly mentioning the listing name, or merely the listing number. Putting backlinks would also improve user experience so we can go back and forth between the listing and the text. For example:

Some text that refers to listing. The explanation contniues....

later in the listing....
Listing1: - Back to text

1: #!/usr/bin/perl 2: use strict; 3: use warnings; ...

The only benefit I can see by using continuation number is that I know right way that it takes around 270 LOCs to build such application in Perl (but the number is not such a big deal).

Hope you can find this useful. Once again, great effort!

1: info and pinfo are pretty standard in Linux box. I don't know the equivalent tools for another OSes

Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!

Replies are listed 'Best First'.
Re^2: RFC: Proposed tutorial - simple login script using CGI::Application
by scorpio17 (Canon) on Jun 20, 2007 at 13:37 UTC

    Thank you for the feedback.

    About the number of modules used... I probably didn't give enough background. When I first began working with CGI::Appliction, creating a login form was one of the first things I wanted to do. CGI::Application assumes you're already familiar with CGI and HTML::Template, so if you're not, there's a fairly steep learning curve (but less so than, say, Catalyst! IMO). Browsing the list of plugins on CPAN (to avoid "reinventing the wheel") I found CGI::Application::Plugin::Authentication. At first, I thought this would be all I needed. But then I realized that it required CGI::Application::Plugin::Storable (unless you want to maintain state with cookies). And it also requires CGI::Application::Plugin::DBH, if you want your passwords stored in a database, instead of a text file. Well, the DBH plugin is really just a wrapper around DBI, so you have to read the documentation for both, but that's still not enough, because at that level it's independent of which database you actually plan to use. Once you decide on, say, mysql, then you have to look up the mysql specific driver modules to learn how to configure things properly, etc. So, what happened to me (and I suspect everyone else that goes down this path) is that you start looking at "just one module" and before you know it you've downloaded about 20 things from CPAN and have two dozen browser windows open to all the various documentation files and while you know all these things are supposed to work together (and each part may, in fact, have good docs and good examples), there is no example of everything put together in final form. So that's what I wanted to do. Too many tutorials are made up of code snippets, and the reader is left having to "connect the dots". The other problem is too much documentation. I am barely scratching the surface of what modules like DBI and Storable are capable of. But for what I want to do, I don't need to know 99% of what's documented - so it's a shame to spend all day reading it trying to find the one detail that you DO need to know.

    As for the line numbers, I'm going to point the finger at Randal Schwartz. I love Randal! And his articles way-back-when in Web Techniques magazine really helped me learn how to program in perl. And he ALWAYS showed complete code listings with each line numbered, for easy reference. So I did my stuff the same way. I agree, it would be nice to upload a working demo online somewhere, maybe with a downloadable tar ball of all the code, to save people from having to download each piece and then strip off the line numbers (oh the horror!). But I don't currently have an ISP that allows CGI scripts, so that's not possible.

    Including backlinks is an excellent idea. I actually had thought of that myself, but was too lazy to do it. I'll try to add that in, later.

    One more thing - regarding my claim that it works. I'm running perl5.8, apache2, and red hat linux (RHEL4). So if anyone out there is trying to develop on win32, er, your milage may vary.

      Hi, scorpio17,
      I'm going to point the finger at Randal Schwartz
      We're referring to the same thing. But I see you only follow him halfway :-) For example, this article is accompanied by a separate listing.
      But I don't currently have an ISP that allows CGI scripts, so that's not possible.
      Check out and try to contact the administrator and see if you can get an account on the server and put your application sample online.

      Adding information about your environment is very good so we might have something to blame on in case something goes unexpected :-)

      Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!