Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Best way to start a perl project

by itztheMonk (Acolyte)
on Jun 01, 2017 at 10:27 UTC ( #1191823=perlquestion: print w/replies, xml ) Need Help??
itztheMonk has asked for the wisdom of the Perl Monks concerning the following question:

Hi,
I would like to know which way to start my perl project( Moderately big project including payment methods while other parts of the system build in perl ). We have the following solutions.
1. Use pure perl with html and logic in the same file
2. Paste the HTML as a perl function on a separate file and require each page when needed and call the the function with data param.
3. Use module Text::Template or Template Toolkit to separate logic and html. I haven't used any of these modules before. Please share any cons and pros for each module.

Since other part of the system is already build in CGI perl. My options is also limitted use CGI perl. But wish to use some kind of templating to separate code and HTML. My main goals include maintainability, reliability, fastness and community support. Thanks

Replies are listed 'Best First'.
Re: Best way to start a perl project
by Your Mother (Bishop) on Jun 01, 2017 at 10:54 UTC

    I agree with Discipulus that #3 is the only sane choice for applications that are either large or likely to grow. I don’t really recommend Template::Toolkit. This is not because I don’t like it, I do, it’s really wonderful, but it’s so deep that it crosses the boundary of template engine and moves into mini-language. It’s also very slow compared to some of the alternatives, including Template::Alloy which can use Template::Toolkit syntax; so it’s the way to go if you want that. Text::Xslate feels shallow by comparison but it’s closer to the ideal of a view (only does presentation and the most basic logic/code and it is variable context ignorant which is kind of unPerly) and it’s terribly fast. As far as that goes, speed in the template layer is not always a prime concern. Depends on the application. Both TT and TX cache templates for performance improvement too.

    Update: typo fix, grazie mille, Discipulus.

      thanks Your Mother for many useful hints,

      if i recall it was possible to cache templates generated by Template Toolkit speeding it up a lot, or I'm wrong?

      oops.. it seems i've not read the whole post. sorry ;=)



      L*

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Re: Best way to start a perl project
by Discipulus (Monsignor) on Jun 01, 2017 at 10:35 UTC
    Hello itztheMonk

    Go for 3, no doubts. Here at PM many experts can expand the many pros.

    I imagine you are speaking of a website.. take a round on the Dancer website for an almost easy to learn web framework and it's related module Dancer2.

    To separate the html from the logic is the first step towards sanity: use Template Toolkit!

    Take also a look to PSGI (the protocol) and plack (the implementation) on CPAN, they took the place of CGI.

    I have a loooot of links about the matter on my homenode



    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Re: Best way to start a perl project
by 1nickt (Monsignor) on Jun 01, 2017 at 11:42 UTC

    Learn and use Template and you will never need to learn another templating solution. Especially if you plan to have a "large" project, use the Template Toolkit.

    One of the reasons to recommend TT is that it is so complete and so stable. What you write now will work in 10 years -- or 20!

    Personally I have never been affected at all by any performance issues with TT. You can cache compiled templates where appropriate. And I've just never come close to the templating being the slow part of any app: almost always, DB access, network access, or disk access are going to be bottlenecks first.

    Finally,as Discipulus recommends, you should use a modern framework for your project, since you are just starting out. Most modern web app frameworks will allow you to specify your templating engine: I strongly recommend using Dancer2 and specifying Template.

    Hope this helps!


    The way forward always starts with a minimal test.
Re: Best way to start a perl project
by davido (Archbishop) on Jun 01, 2017 at 15:48 UTC

    #1 was how it was done (poorly) in the late 90's and early 2000's when everybody dabbled in web programming with CGI.

    #2 sounds more like "about the best you could do with Perl 4."

    #3 is the only sane option of the options mentioned for new work this century, though could be expanded to use other templating systems (the ones you mentioned are fine, but there are other reasonable options too), and even well-architected MVC frameworks such as Dancer or Mojolicious.


    Dave

Re: Best way to start a perl project
by scorpio17 (Abbot) on Jun 01, 2017 at 12:50 UTC
Re: Best way to start a perl project
by SimonClinch (Deacon) on Jun 01, 2017 at 20:17 UTC
    I like template toolkit, but I am often prevented from using it and with good reason: "good" web development (tm) depends on being able to separate style from content and TT is an insufficient framework for that. At some point you'll be forced to think in terms of custom framework - it happens to everybody eventually.

    One world, one people

      I disagree about rolling a custom framework; unless a company is in the business of making frameworks. There are many template frameworks in Perl at all levels of control and most have communities and available devs and test suites and documentation and free bug fixes. 15 years ago maybe, maybe, it would have been worth rolling a new solution for a specific problem. Today there is no developer who could produce a better engine economically—including tests and documentation and answering questions for the other devs/designers—than at least one of the options on the CPAN.

      Rolling your own template engine is long considered a newbie rite of passage undertaken specifically because one doesn't know any better.

        When I say custom framework I do not mean rolling your own components of that framework. Modern frameworks are best called meta-frameworks because customisation is unavoidable and in fact NOT customising the meta-framework to meet your needs is the semi-newbie mistake because it means code design has been severely limited at best.

        One world, one people

      Probably one-third of the projects I have worked with did use a home-grown solution, especially when those projects have been around for a long time such that they were originally built for much-smaller hardware.   I suspect that many of the more-lightweight tools that we see today in CPAN are contributions made from these.

      If you are at the luxurious point where you still can make a decision, knowing of course that whatever decision you make will wind up being permanent, I would strongly advise anyone to try to make the decision as a team, by consensus.   Have several team members choose a different CPAN tool, and have all of them take a couple days familiarizing themselves with the tool and writing some moderately-representative web page using it.   Then, circle the wagons and have the team members de-brief the others.   Invite each of them to present at least three reasons why the project should use this tool, and at least three other reasons why not.   Remind them that all reasons should be technical.

      I would suggest that efficiency – that is to say, machine efficiency – is probably a much-less important factor today than it was in years past.   But, team efficiency, maintainability, and expressiveness are more-so.   Whatever tool you they choose, realize that the choice is being made forevermore.

      Indiana Jones and the Last Crusade:   “He did not choose ... wisely ...”

Re: Best way to start a perl project
by sundialsvc4 (Abbot) on Jun 01, 2017 at 18:01 UTC

    Like all the others, I will echo the opinion that you should “use Template Toolkit, and never look back.”   You definitely want to cleanly separate the concern of “what does the HTML page look like” from the concern of “what should go in it,” and TT is a rugged, efficient solution that is used all over the world in countless production web sites.   Although it is very expressive and therefore also seemingly-complicated at first glance, it is a dependable work-horse that also wins horse-races.   (I’ve worked on plenty of Perl projects over these many years, and I can count on the fingers of one hand the projects that didn’t use it.)

      Like all the others…you should “use Template Toolkit…” You definitely want to cleanly separate the concern of “what does the HTML page look like” from the concern of “what should go in it,” and TT is a rugged, efficient solution…

      Holy crap. All the others? This is the opposite of what I said and it’s wrong besides. TT being a mini-language promotes unclean code by affording complex logic and directives in the View layer and TT is the most inefficient Perl template engine in common use.

        We simply have a functional difference of opinion, “Mom.”   I have over these many years worked on plenty of projects where it seemed to be doing the job just fine.   However, I would also observe, both that it has since had many successors, and that a template-engine decision once made is almost never re-made.   The project sticks with the devil it knows, as the years and then the decades go by, even though it now knows it to be a devil.

        In terms of the original post, I think that the most important consideration is – always – “separation of concerns.”   The Marketing Department™ is never still.   They always want to make changes, although many of those changes are no more than cosmetic window-dressing, and ... “well, let me just say that one of the other projects that I am shepherding right now is written in (old) PHP.”   There is of course no way to remove that project from that rabbit-hole, but even a seemingly-innocuous change is tedious and expensive there.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1191823]
Front-paged by Corion
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2018-06-18 08:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?



    Results (109 votes). Check out past polls.

    Notices?