Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Unsatisfactory state of Module::Starter stack

by SilasTheMonk (Chaplain)
on May 19, 2010 at 18:39 UTC ( [id://840759]=perlmeditation: print w/replies, xml ) Need Help??

Replies are listed 'Best First'.
Re: Unsatisfactory state of Module::Starter stack
by jaldhar (Vicar) on May 21, 2010 at 14:11 UTC

    Hmm I thought I replied to this yesterday but the node appears to have been eaten.

    Anyway Silas could you go into more detail about why Module::Starter::Plugin::CGIApp "really goes too far"? I am always looking for ways to make this module more useful.

    --
    જલધર

      It's largely a matter of personal preferences. My template files end in ".tmpl" for example. Also I would want to include some extra files, like certain template files, a minimal CSS files, a .png that I always use etc etc. I got the impression that your module was simply an expression of your personal preferences and I could not see a point in requesting changes based on personal preferences. Nor could I see any value in trying to derive from such a class. So it needs to be a lot more flexible to be useful to me (though of course the defaults can reflect your personal preferences). I suppose philosophically, a Module::Starter::CGIApp has gone too far by its very choice of name. A module that was sufficiently flexible to be of use to me in this context, could be used for things that were not related to CGI::Application. This is why I am drawn to the module that simply tries to derive from Module::Starter::Plugin::Template by filling in the abstract methods with a choice of templating engine. True it is not my favourite templating engine, but this sounds a better bet than any other option.

        It's largely a matter of personal preferences. My template files end in ".tmpl" for example.

        Hmm that doesn't sound like it would be too hard to add. I'll consider it for the next version.

        Also I would want to include some extra files, like certain template files, a minimal CSS files, a .png that I always use etc etc.

        Now here we run into the limitations of the Module::Starter architecture. Dist::Zilla with its plugins is far more flexible for what you want to do.

        I got the impression that your module was simply an expression of your personal preferences and I could not see a point in requesting changes based on personal preferences. Nor could I see any value in trying to derive from such a class. So it needs to be a lot more flexible to be useful to me (though of course the defaults can reflect your personal preferences).

        Well yes to some extent that's true but only because one has to start somewhere. I would like this module to follow the best practices in the CGI::Application community and in general be as useful to as many people as possible but I can't do that if I don't get feedback.

        I suppose philosophically, a Module::Starter::CGIApp has gone too far by its very choice of name. A module that was sufficiently flexible to be of use to me in this context, could be used for things that were not related to CGI::Application.

        FWIW, I use this module to start non-CGIApp modules too. Even though I have to manually remove all the CGIApp bits, it's still less drudgery than creating a distribution by hand.

        --
        જલધર

Re: Unsatisfactory state of Module::Starter stack
by metaperl (Curate) on May 21, 2010 at 20:31 UTC

      Module::Starter has a good pass record, good reviews, a fairly small bug list and is comfortingly unambitious. What is there not to like? I wasn't complaining about Module::Starter per se but rather that modules that have not been derived from it.

      I had a very brief look at Dist::Zilla. It fails to sell itself to me (perhaps they need to hire a copywriter). In particular it clearly attempts to be a much more comprehensive system than Module::Starter. If they succeed this is of course a virtue, but I am just left with an aching feeling that is bound to incompatible with me somewhere.

      My approach at the moment is to identify where I am wasting time and find a solution - one problem at a time. I'm happy to write or partly write some stuff myself, but obviously I come to CPAN first. One problem at a time seems a more robust approach than trying to find a one stop shop.

        In the end Dist::Zilla doesn't need a copywriter because it's not trying to sell itself to anyone. Its main virtue, in my eyes, is being useful to me. If other people get mileage out of it, that's cool, too.

        As for the "dzil new" command, which is the "Module-Starter-like" bit, it's very young. I think it's also very good and has a lot of promise, but its main form of documentation right now is a screenshot of it getting used in my blog. The explanation for this isn't interesting to many people, and goes something like, "documenting it before the global config subsystem that will enhance it is complete would be a waste of time because of the changes to docs that it would require later."

        That said, if you stop by irc.perl.org #distzilla, there are almost always people there who can help you use it. I think you will find it much more flexible than Module::Starter, which was very hard to extend as time went on. Its that technical inflexibility that led me, in part, to stop using it.

        rjbs
        I had a very brief look at Dist::Zilla. It fails to sell itself to me (perhaps they need to hire a copywriter).
        That's one of my irks about Ricardo Signes. Most of his modules are DEEPLY underdocumented and it's not always clear what practical use they have. But I'm speaking as the general public. Ricardo rolls deep on irc.perl.org in #moose with all the heavy hitters. They work around the clock as a dedicated pack of hackers in a cooperative non-elitist fashion.

        When he puts out a module its because that pack of hackers COLLECTIVELY see it as a best of breed choice having surveyed everything out there.

        In particular it clearly attempts to be a much more comprehensive system than Module::Starter. If they succeed this is of course a virtue, but I am just left with an aching feeling that is bound to incompatible with me somewhere.
        Yes, I agree. I still use Module::Starter myself. But if you join the IRC channels and chat them up, they will be glad to discuss their aims and bring you in to submit patches, etc. And also why they started a new project instead of extending Andy's.



        The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development.

        -- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"

Re: Unsatisfactory state of Module::Starter stack
by Anonymous Monk on May 19, 2010 at 23:24 UTC
    FYI, SOPW is for questions, Meditations is for observations you'd like to make. Thanks.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://840759]
Approved by Arunbear
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (5)
As of 2024-03-29 15:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found