Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: CGI::Prototype leverages objects for web app control

by Anonymous Monk
on Oct 19, 2009 at 14:03 UTC ( #801992=note: print w/ replies, xml ) Need Help??

Comment on Re^2: CGI::Prototype leverages objects for web app control
a Moose CGIP shall not receive merlyn's blessing
by metaperl (Curate) on Oct 19, 2009 at 16:53 UTC
    I have forked CGI::Prototype and wrote a Moose version that I wanted merged back into the distro, but merlyn refuses to have a standard Moose-based CGI version of CGIP in the distro - he said it had to use prototype OO.

    As such, I have reserved the namespace CGI::Class but not released anything to CPAN.

      Please don't misquote me.

      I never said that a Moose-based CGIP was out of the question.

      I said a non-prototype-Moose base class would not be acceptable.

      All you have to do is use a prototype-Moose base class, which either exists already, or is just a small matter of programming.

      Or, you can go off and do what you want. Just don't call it CGI::Prototype until it's prototype-based.

      -- Randal L. Schwartz, Perl hacker

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

        Please don't misquote me. I never said that a Moose-based CGIP was out of the question. I said a non-prototype-Moose base class would not be acceptable.
        Yes, that's right. I was typing in a hurry and made an overly general statement. My apology.
        All you have to do is use a prototype-Moose base class, which either exists already, or is just a small matter of programming.
        I would rather lean on standard Moose
        1. so I can leverage all the Moose extensions that exist
        2. so I dont have to worry about a splinter project and its potential bugs
        Or, you can go off and do what you want. Just don't call it CGI::Prototype until it's prototype-based.
        1. You should change your docs. You say that CGIP creates a CGI application by subclassing which implies class-based OOP
        2. You should improve your docs (similar to my fork). When people scan your docs or your Linux magazine articles, they see nothing that cant be done just as easily with class-based OOP or CGI::Application. You need to motivate the unique position of this module with some exemplary sample code SOMEWHERE
        3. Please embrace the multiple concepts of prototype. A CGI prototype could be something which prototypes the CGI request cycle. And CGIP does an excellent job of that, regardless of which object system it uses. There's no need for a separate distribution for something which has largely the same code.
      I can see merlyns point to some degree, however I've not used Moose (and have no immediate plans so to do) but surely, implementing CGI::Prototype as you suggest would introduce previously unneeded dependencies, on the part of existing code, on Moose i.e. removing any backward compatibility ... or have I, not for the first time, missed something otherwise obvious ?

      Surely you should be reserving/creating a new namespace e.g. CGI::Prototype::Moose, to make the provenance abundantly clear to all and sundry - in a manner that the namespace CGI::Class doesn't.

      A user level that continues to overstate my experience :-))
        I can see merlyns point to some degree, however I've not used Moose (and have no immediate plans so to do) but surely, implementing CGI::Prototype as you suggest would introduce previously unneeded dependencies, on the part of existing code, on Moose i.e. removing any backward compatibility ...
        Upgrading to the use of Moose would wreck backwards compatibility with any previous CGI::Prototype apps. However, note that you say: "implementing CGI::Prototype as you suggest". merlyn has no issue with Moose for a newer CGIP. He has an issue with standard Moose. So either of our approaches to adding Moose would cause this problem.
        or have I, not for the first time, missed something otherwise obvious ?
        The issue would be what new apps would run on. And, assuming that the new module with the new implementation is named something other than CGI::Prototype, then new code would simply use this different as its base class.
        Surely you should be reserving/creating a new namespace e.g. CGI::Prototype::Moose, to make the provenance abundantly clear to all and sundry - in a manner that the namespace CGI::Class doesn't.
        Well, initially I wrote such a module and planned for it to be part of the standard CGIP distro. But merlyn has made it clear that any standard Moose CGIP will not be in the CGIP distro, hence the name change.

        I think using CGI::Prototype::Moose would make him uncomfortable and I certainly dont intend to narrow my approach to Moose forever. There were class-based OO before Moose and may be afterwards (though I doubt it).

        Moose is the current chosen object layer for a class-based implementation of CGI::Prototype. I dont think the object layer itself need be in the module name. For instance both Catalyst and DBIx::Class are being re-implemented in Moose but retaining their current name. Likewise, I have a number of modules on CPAN that use Moose (e.g., Number::Closest) but the dont have Moose in their name.

        Should Class::DBI have been named Class::DBI::Accessor::Fast?

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (8)
As of 2014-07-11 09:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (224 votes), past polls