Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Re: Re: Why CGI::Application?

by DrHyde (Prior)
on Jan 14, 2004 at 10:55 UTC ( [id://321228]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Why CGI::Application?
in thread Why CGI::Application?

As another poster stated, it started me thinking about my webapps as state machines and that has been a good thing.

It most certainly is a good thing!

Maybe your apps don't need that, if you have a simple CGI that does one thing only - then probably not. But once you get into a multi-step, multi-form, webapp, CGI::Application is definetly a plus.

CGI::Application makes it no easier to write multi-form applications as far as I can tell. All my form submissions have an action=foo parameter. The various foos have sensible names and simply make the big if ... elsif ... else block call the appropriately named subroutine. This is exactly the same as CGI::Application's "run modes"

If you have the time or inclination, please write up what irritated you.

It irritates me because it provides nothing useful, while wrapping itself up in grandiose language about how it will make the web application world a better place.

Give us examples of how your approach is better ...

I can't give you the code, but I consider it to be better because it has fewer dependencies while requiring me to do just as much work, and because it's one less thing for someone else to have to learn before maintaining my code.

are you sure it wasn't the small learing curve for CGI::Application that just got in the way of you delivering the product.

What learning curve? CGI::Application is far simpler than some of the other modules I'm using.

I should write this up as a review for cpanratings.

Replies are listed 'Best First'.
Re: Re: Re: Re: Why CGI::Application?
by demerphq (Chancellor) on Jan 14, 2004 at 20:28 UTC

    I can't give you the code, but I consider it to be better because it has fewer dependencies while requiring me to do just as much work, and because it's one less thing for someone else to have to learn before maintaining my code.

    Your logic is horribly flawed. You just _added_ to the code that your maintainance crew will have to work with. Not only that but your code almost certainly doesnt work the way the other project coded in your firm that used similar rationale. Now they have to know how two different rolled-yer-own systems handle things.

    If you had stuck to CGI::Application, your maintainence crew would have the support of thousands of programmers with considerable experience in using it, they would have recourse to an external party with considerable skill (and from my experience a desire to help) to resolve ongoing issues in the code. Simply upgrading to the latest release would probably resolve all the maintainence issues associated with the handler. Not to mention other issues like security patches etc.

    Just to rub the point in, did you roll your own CGI as well?

    PS: I am not a knee jerk, use the modules kind of guy. But if you are going to reinvent a well established, tried and tested wheel, it had better be superior to the wheel you rejected. And frankly given your response Im doubtful.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


      Your logic is horribly flawed. You just _added_ to the code that your maintainance crew will have to work with.

      Don't be stupid. I had to write just as much code. Not more code.

      Not only that but your code almost certainly doesnt work the way the other project coded in your firm that used similar rationale.

      Yes, quite possibly, although this is the first large webby app we have and IME using the same techniques for titchy apps and large apps is not always a good thing anyway. Not that that is important. This uses an if statement rather than a not-particularly-mainstream perl module. If someone finds maintaining an if statement too complex for his poor little brane, then he shouldn't be maintaining code at all, and would certainly find a CGI::Application solution (which would of course use if statements elsewhere in it anyway) far too difficult.

      If you had stuck to CGI::Application, your maintainence crew would have the support of thousands of programmers with considerable experience in using it

      Yes, there's so many people using CGI::Application that I hadn't even heard of it until a couple of months ago.

      they would have recourse to an external party with considerable skill (and from my experience a desire to help) to resolve ongoing issues in the code.

      If they have trouble with if statements then they also have recourse to external parties with considerable skill (and from my experience a desire to help). Such as the perl-beginners mailing list, this august forum, their local perl mongers, and the Llama book.

      Simply upgrading to the latest release would probably resolve all the maintainence issues associated with the handler. Not to mention other issues like security patches etc.

      What CGI::Application does is so damned simple that having any security issues in it should be a shooting offence. It's just a glorified if statement. I am quite certain that I have not introduced any security bugs into my code through my use of an if statement. If I have, I promise to eat my hat and post a link to the video here.

      Just to rub the point in, did you roll your own CGI as well?

      Yes! I also decided that I didn't like Mr. Wall's implementation of perl, and so wrote my own in lovingly hand-crafted assembler! Next, I'll be replacing that nasty operating system thing! I think I'll write it in Postscript!

        While I have tended to agree with many things you've said, and I especially like your stick-to-it attitude, I'm going to take issue with one thing in your reply.

        Yes, there's so many people using CGI::Application that I hadn't even heard of it until a couple of months ago.

        There are literally hundreds of Perl modules that I've never heard of that have thousands of users, and I've been writing Perl for a living since 1995. For example, I learned how to use File::Spec 6 months ago. Same with File::Basename. In fact, I'd never heard of them (save as a quick mention in the Camel book) ... till I needed them. I had never needed to do file-level operations before (or since), so I never looked.

        To bring the point closer to home, I develop large-scale web applications for a living. I've been doing this for at least 2 years now. Two weeks ago was the first time I'd taken a close look at CGI::Application. Why? I could never have implemented it if I'd wanted to. The current app I'm on is the first time since 1995 that I'm implementing a new application from scratch. C::A is an infrastructure decision you can't make 4 years into a project.

        A lot of people are in a similar situation. You want to try this C::A thing, but you can't because the app you're working on already has an infrastructure. This doesn't mean you don't want to try it. This doesn't mean you don't think it's a good idea. I've been itching to try this module for about a year now, but never looked at it closely, because I couldn't play with it at work.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://321228]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-04-16 19:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found