http://www.perlmonks.org?node_id=411768


in reply to Review: CGI::Prototype

Unfortunately, I don't have time to address every point of your review, since I'm sitting in an airport and will need to leave soon. Let me address some of the more critical aspects:

The version number is 0.90 because the internal release at the customer site is 0.85, because they're already using it in their production and putting something like "0.15" into production would have been a bit embarassing. But to me, it does feel like about a 0.35 release, if that helps.

To acknowledge prior art would be to acknowledge every MVC framework I've seen. I didn't look at just one package. I've looked at dozens. This is not the heir apparent to CGI::Application any more than it's the descendant of Smalltalk's MVC pattern from my studies in 1981.

For said client, I was initially steered towards CGI::Application, and started liking the externals, but then was also told to stare at the internals and I'm glad I did. Huge subroutines covering hundreds of lines of code. And not quite the right callbacks that I needed, which would have meant a careful understanding of those monolithic subroutines to cut and paste, not just override callouts for callbacks.

What I did for the design of CGI::Prototype was Keep It Simple. Very Simple. No subroutine is longer than a dozen lines. Plenty of places to override all the built-in decisions. And yes, I went with Template Toolkit, because I hate HTML::Template, because I hate angle bracket languages in general for human editing. However, overriding engine and render would be trivial to use HTML::Template. I just don't describe it because I don't want to waste time encouraging it.

The way you design CGI apps is probably just another style that CGI::Prototype would need a different skin for. The "one page is one class is one file" is a specialization of CGI::Prototype::Hidden that happened to work for the three projects in which I'm currently developing. But I predict that other specializations are also possible for other styles.

So, in conclusion, I'm not rewriting CGI::Application. I'm designing a generic controller for use with CGI applications that encourages subclassing as a means of specialization. That hasn't been done yet (CGI::Application doesn't qualify, because it's too specific and not tweakable enough). I'm also developing applications with this framework and will probably continue to add other specific subclasses for other styles. Maybe even a CGI::Application compatibility layer, for example, as well as an Apache::MVC compatibility layer.

Your review presumes some things about the purpose of CGI::Prototype that are inappropriate. I'll take the blame for not communicating that more clearly. But many of the people I've shown are excited by some of the potential of this module. So I'll take that as positive feedback, and move on.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re^2: Review: CGI::Prototype
by samtregar (Abbot) on Dec 02, 2004 at 17:48 UTC
    And yes, I went with Template Toolkit, because I hate HTML::Template, because I hate angle bracket languages in general for human editing.

    It must have really bothered you to write your post then, right? HTML is an angle-bracket language for human editing! It's not my favorite either but it seems silly to critique an HTML templating system for using angle brackets.

    Of course, it's easy to use to the filter option to HTML::Template->new() to allow [tmpl_var foo] if that's what you want!

    -sam

      Your module HTML::Template ist still one of the most popular ones out there. I've seen ports for python, php and ruby. It's famous! Merlyns opinion is just his personal point of view - and of course that's okay.

      best regards,
      neniro

        I ported it to ASP and Java too. Thinking about C# when time allows :)
Re^2: Review: CGI::Prototype
by dragonchild (Archbishop) on Dec 02, 2004 at 14:47 UTC
    That hasn't been done yet (CGI::Application doesn't qualify, because it's too specific and not tweakable enough).

    When you have time, please elaborate on this statement. The cgi-app mailing list has been working on dozens of improvements for tweaking and reducing the specificity of how the internal functions work. I know - I've been involved in a lot of it. We would love to have your input on how we can improve, in as much detail as you'd care to provide.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      When you have time, please elaborate on this statement.
      Well, here's my bottom line on that.

      When I looked at CGI::Application, I concluded what I've already said. And then I went off to commit time to make my own framework.

      Since I already have CGI::Prototype in development and deployed at a few customer sites, it's not likely that anything I say now will want me to jump back over to some future version of CGI::Application. Not gonna happen.

      If you're developing CGI::Application, feel free to steal ideas as you are inspired to do so by CGI::Prototype's design, but any hour I spend working out the differences between the two is an hour I'm not able to bill to my customers to develop the framework they've chosen on my suggestion.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        I got some XP/karma to burn ... ;)

        There seem to be a lot of I's and selfishness in this approach (and post). Instead of committing time to improving cgiapp, you decided to re-invent the wheel. Why? The cgiapp community would have gladly accepted your input!

        Now you're immersed into your framework and deem it better than cgiapp, which will carry a lot of weight, given who you are. You've also "locked in" some of your clients, which is fine & dandy for you, especially job-security-wise. But I gotta think this is harmful overall to the spirit of Open Source if there are numerous wheels to the same solution.

        This whole thing just comes off to me as a I-know-better-than-you kinda thing.