I've been having an agruement with a friend that Mason (Perl) is not a framework, but a templating language. I feel Mason for Perl does what JSP does for Java (as an analogy, not pure technical comparison). From what I know, JSP is not a framework and I feel neither is Mason. When I looked up wikipedia Mason (Perl), I see that the main site says it is a web application framework written in Perl while the discussion page contests it.
Any pointers on why it is/ it is not a framework?
Update based on comments from ysth:
For a framework, I feel it should at least make db access easy, manage sessions, basic security that a webapp would need, templating and code reuse (or libraries that make basic tasks easy).
Mason is an 'M' short of being a MVC (Model-View-Controller) framework. It provides extensive rendering (View) features, which is why people think of Mason as being a templating language. However it also provides quite a few dispatch mechanisms (epsecially in the form of dhandlers), and control mechanisms (which fit naturally into autohandlers).
A few years ago I wrote an on-line tutorial (in Mason) to show off some of these features. It's optimised for full-screen display, and needs javascript enabled.
What Mason doesn't give you is a database abstraction layer, so you have to bring your own Model.
To the best of my knowledge amazon.com is written in Mason, along with many other sites.
If you enjoy working with Mason, but you'd like to have a Model, more toys, and a pony, then you may consider looking at Jifty as a web application framework.
A templating system would be something like HTML::Template, that is, a module that only does templating.
I feel that Mason does more, it has somehow a routing mechanism, it provides argument handling though %ARGS, intialisations through %INIT.
It also provides interfaces to mod_perl, CGI...
Now, it does not talk to the database, as if you want a clean way to do it, you'll have to use Class::DBI, DBIx::Perlish or one of the other hundred perl modules that does object mapping, or whatever else...
It is not an Model-View-Controller type of framework, it is probably closer to PHP than Ruby on Rails for example (and just as bad from what I have seen of it).
Can't answer the question to whether HTML::Mason is or isn't a framework without looking at it but I'm always happy with the following definition....
"a framework calls your program whereas your program calls a library"
Looking at Embedded Perl in HTML with Mason view of its competition, I'd say it is a template language. Otherwise Catalyst and Maypole would be on the list. Also, I think I read somewhere that you can use Mason as the View portion in a Catalyst application.
I guess I can see where you can use it like a framework, but it seems to be more complete if you view it as a template language.
Mason alone is not a framework it's just a template system BUT with some very cool features. It's got it's own structure and you can embed perl code very easely in it also it's got cache support. I've seen people who use Mason alone for developing a large application, but I guess it works better in an MVC framework.
Take care!
The following definition of a framework is taken from the Gamma book on Design Patterns. "A framework is a set of cooperating classes that make up a reusable design for a specific class of software." Mason, by that definition, is a framework. An MVC framework is only one type of framework.
HTML::Mason is what frameworks want to become when they get older. With HTML::Mason you get:
a dispatcher
templating
caching
logging
extremely flexible modularization
It was designed for high performance multi-tiered web applications, not for pleasing the fans of design patterns borrowed from desktop programming (such as MVC was).
Depends of your definition of framework.
You can apply name framework to any library if it does more than one thing.
Related
I'm familiar with jquery and javascript but i'm a python noob. Whenever I learn something about python on the web, there's mention of django here and there. When i went to the official django site, it described it as "Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design." So I inferred it's what jquery is for javascript, am I correct?
[This might seem like a silly question but I tend to get shameless when it comes to asking questions on stack**overflow**]
I don't think it's a very useful comparison.
JQuery is mostly a wrapper around core functionality of javascript. Partly to make it easier to use and partly because otherwise you'd have to deal with browser specific problems even for the most basic scripts.
Django is a full-featured web framework that has many useful and necessary things built-in. It has request routing, templating, database abstractions, localization and a lot more.
In contrast to other web-frameworks it has those things tightly coupled and is opionated on what's the best practice to build your website with it.
A better comparison in the JavaScript world is (as an example) AngularJS. It also comes with lots of good features (routing, templating, data-bindings, dependency injection, etc.) but when you use it, you should better stick to "the angular way" of doing front-end JavaScript.
Think of JQuery more of a low-level library that you can build your code and even frameworks like AngularJS on. Kinda like the standard library of Python.
The short answer: Kind of- it is in the sense that JQuery is essentially a set of useful bits of code written in Javascript and Django the same in Python. However, JQuery is a more functional framework, where as DJango is more like a CMS framework.
No question is a silly question!
Almost, but not exactly.
I would say your python to javascript comparison is correct (as Python can be used as a scripting language for web applications, just like javascript), but jQuery is not exactly like Django.
jQuery is a library designed to simplify the scripts needed for dynamic website functionality, whereas Django is more useful in the creation of complex, database-driven websites.
A few years ago I did a lot of work with CGI.pm. I'm evaluating using it again for a quick project. Can someone bring me up to speed on the current state of developing with CGI.pm in the "Web 2.0" world? What are the best libraries on CPAN to use with it? Are there clean ways to include jQuery, YUI, other CSS libs, etc, and do some AJAX. There are of course lots of libraries on CPAN but what works and what is commonly used?
We aren't still doing this?
$JSCRIPT<<EOF;
...
EOF
I realize people are going to offer Catalyst as an answer. However, many people may have legacy CGI.pm apps they simply want to enhance. Is starting over really the best answer?
Personally, I'm no fan of Catalyst (too heavy for my taste) or Mason (mixing code and HTML is bad ju-ju), but I do quite well using CGI.pm for input[1], HTML::Template for output, and CGI::Ajax to provide AJAX functionality where called for.
If you're looking at frameworks, you may also want to consider CGI::Application, which is a widely-used and lighter-weight alternative to Catalyst/Mason.
[1] I can't recall the last time I called anything other than $q->param or $q->cookie from CGI.pm. There are still a lot of tutorials out there saying to use its HTML-generation functions, but that's still mixing code and HTML in a way that's just as bad as using here docs, if not worse.
Consider using something more modern, for example Catalyst. It will make your life much easier and you won't have to reinvent the wheel. I understand that it is just a small project, but from my experience many small projects in time become large ones :)
The "web 2.0" apps that I've worked with usually use client-side JavaScript to request JSON data from the server, then use that data to update the page in-place via DOM.
The JSON module is useful for returning structured data to a browser.
As far as including JavaScript, HTML, or whatever in a here doc - that was never a good idea, and still isn't. Instead, use one of the plethora of template modules to be found on CPAN. For a CGI, I'd avoid "heavy" modules like Mason or Template Toolkit, and use a lighter module for quicker startup, such as Text::Template, or Template::Simple.
Yes, you can write perfect web2.0 web applications WITHOUT using any framework on the server side in any language Perl, Python, Java, etc and WITHOUT using any JavaScript libraries/framework on the client side. The definition of web 2.0 is kind of a loose definition, and I'm guessing by web2.0, you mean Ajax or partial page refresh, then all you would really need is to focus on the following:
Know about the XmlHttpRequest object.
Know how to return JSON object from the server to the client.
Know how to safely evaluate/parse the JSON object using JavaScript and know to manipulate the DOM. Also, at least know about innerHTML. InnerHTML is helpful occasioanally.
Know CSS.
Having said that, it's a lot easier to use some framework on the server side, but not because it's required by web2.0 and it's a lot easier to use some JavaScript on the client like jQuery, mootools, YUI. And you can mix-and-match depends on your needs and your tastes. Most JavaScript provides wrapper around the XmlHttpRequest so that it works across all browsers. No one write "naked" XmlHttpRequest anymore, unless you want to show some samples.
It's perfectly possible to write "Web 2.0" apps using CGI.pm, but you'll have to do the work yourself. From what I've seen, the focus in the Perl development community has been on developing successor frameworks to CGI, not on writing helper modules to let legacy apps get bootstrapped into modern paradigms. So you're somewhat on your own.
As to whether to start over, what are you really trying to accomplish? Everyone's definition of "Web 2.0" is somewhat different.
If you're trying to introduce a few modern features (like AJAX) to a legacy app, then there's no reason you need to start over.
On the other hand if you're trying to write something that truly looks, feels, and works like a modern web app (for example, moving away from the page-load is app-state model), you should probably consider starting from the ground up. Trying to make that much of a transformation happen after the fact is going to be more trouble than it's worth for anything but the most trivial of apps.
I agree with Adam's answer, you probably want to use Catalyst. That being said, if you really don't want to, there's nothing preventing you from using only CGI.pm. The thing is, Catalyst is a collection of packages that do the things you want to make Web 2.0 easy. It combines the various templating engines such as Template Toolkit or Mason with the various ORM interfaces like DBIx::Class and Class::DBI.
Certainly you don't have to use these things to write Web 2.0 apps, it's just a good idea. Part of your question is wondering if javascript and CSS frameworks like jQuery, or prototype require anything from the server-side code. They don't, you can use them with any kind of server-side code you want.
For new apps, if you don't find Catalyst to your taste, Dancer is another lightweight framework you may like. There are also plenty of others, including CGI::Simple, Mojo/Mojolicious, Squatting...
Any of these lightweight frameworks can take care of the boring parts of web programming for you, and let you get on with writing the fun parts the way you want to.
If the jump from CGI.pm to Catalyst seems too daunting then perhaps something like Squatting might be more appropriate?
Squatting is a web microframework and I have found it ideal for quick prototyping and for replacing/upgrading my old CGI scripts.
I have recently built a small "web 2.0" app with Squatting using jQuery with no issues at all. Inside the CPAN distribution there is an example directory which contains some programs using jQuery and AJAX including a very interesting [COMET](http://en.wikipedia.org/wiki/Comet_(programming)) example which makes use of Continuity (which Squatting "squats" on by default).
NB. If required then you can later "squat" your app onto Catalyst with Squatting::On::Catalyst
There is also CGI::Ajax.
Scaffolding, what is it? Is it a Rails-only thing?
Scaffolding generally refers to a quickly set up skeleton for an app. It's not rails-only since other platforms have it as well. It's also not generally meant to be a "final" system; merely the first, smallest way to do it.
From Wikipedia:
Scaffolding is a meta-programming
method of building database-backed
software applications. It is a
technique supported by some
model-view-controller frameworks, in
which the programmer may write a
specification that describes how the
application database may be used. The
compiler uses this specification to
generate code that the application can
use to create, read, update and delete
database entries, effectively treating
the template as a "scaffold" on which
to build a more powerful application.
Just like a real scaffolding in a building construction site, scaffolding gives you some kind of a (fast, simplified, temporary) structure for your project, on which you can rely to build the real project.
It can be (and is today) used to describe many things - from abstracting DB layers, to web apps folder structures, and to generating and managing project dependencies .
It is not something that is specific to any language / technology, just like the term skeleton or boilerplate is platform agnostic.
It is just a term borrowed from real scaffolding (like mentioned above).
You build some fast, simplified, (sometimes external, sometimes temporary) structure that will help you to build the real, more complex, finalized structure under, above, inside or outside of that temporary structure .
.. And just like the real scaffolding, the scaffolding structure is meant to support the building process of the project, rather than the project itself (with some exceptions).
Scafolding is usually some type of code generation where you point it at a database, and the technology creates basic CRUD (create, read, update, delete) screens.
I believe that Wikipedia and some answers here provides a narrow and restricted view. Scaffolding is not just for CRUD operations on top of a database. Scaffolding has a broader objective to give you a skeleton app for any kind of technology.
Yeoman is a modern and useful tool for scaffolding. Using their own words:
The web's scaffolding tool for modern webapps
What's Yeoman?
Yeoman helps you to kickstart new projects, prescribing best practices
and tools to help you stay productive.
To do so, we provide a generator ecosystem. A generator is basically a
plugin that can be run with the yo command to scaffold complete
projects or useful parts.
Through our official Generators, we promote the "Yeoman workflow".
This workflow is a robust and opinionated client-side stack,
comprising tools and frameworks that can help developers quickly build
beautiful web applications. We take care of providing everything
needed to get started without any of the normal headaches associated
with a manual setup.
With a modular architecture that can scale out of the box, we leverage
the success and lessons learned from several open-source communities
to ensure the stack developers use is as intelligent as possible.
As firm believers in good documentation and well thought out build
processes, Yeoman includes support for linting, testing, minification
and much more, so developers can focus on solutions rather than
worrying about the little things.
That's it. Use scaffolding to create a quick-start application to work as an example or the foundation of your solution. It makes you productive faster them building things from scratch.
It is not a rails only term although I think it originated there (at least that is where I first heard it.)
Scaffolding is a framework that allows you to do basic CRUD operations against your database with little or no code. Generally, you then go through and add the code to manage the data the way you want replacing the scaffolding. It is generally only intended to get you up and running quickly.
No it is used in other technologies also such as ASP.NET MVC
it creates a basic layout from some predefined code which programmers uses in almost every project , Eg: for database data access it can make a crud method for create, read, update, delete operations
OR you might use it to create layout for your View/Html Code
Scaffolding is writing any piece of code that would not be part of the business logic but would help in unit testing and integration testing.
This is a software engineering term and not bound to any framework or programming language.
No, scaffolding is not the term for the specific platform, however many know this term in the context of Ruby on Rails or .NET
There are also plenty of tools that perform javascript scaffolding:
divjoy.com
flatlogic.com
scaffoldhub.com
yeoman.io
Those tools are also known as code-generators
Scaffolding is the term used when you don't want to create all parts of the structure such as models, views, etc. and want to generate them all in one go. A lot of frameworks use this technique, I studied about it while doing odoo but most of the references given were to ruby on rails :)
Every time I see Ruby or Python discussed in the context of web development, it's always with a framework (Rails for Ruby, Django for Python). Are these frameworks necessary? If not, is there a reason why these languages are often used within a framework, while Perl and PHP are not?
I can only speak towards Ruby - but, no, you don't need a framework to run Ruby based pages on the web. You do need a ruby enabled server, such as Apache running eruby/erb. But, once you do, you can create .rhtml files just like RoR, where it processes the inline ruby code.
The short answer is no, they are not necessary. In ruby you have .erb templates that can be used in a similar way as you use PHP pages. You can write a site in ruby or Python using several technologies (Rails-like frameworks, Templates or even talking directly with the HTTP library and building the page CGI-style).
Web frameworks like Python's Django or Ruby's Rails (there are many) just raise the level of abstraction from the PHP's or ASP's, and automate several process (like login, database interaction, REST API's) which is always a good thing.
"Need" is a strong word. You can certainly write Python without one, but I wouldn't want to.
Python wasn't designed (like PHP was, for example) as a direct web scripting language, so common web-ish things like connecting to databases isn't native, and frameworks are handy.
EDIT: mod_python exists for Apache, so if you're merely looking to write some scripts, then Python doesn't need a framework. If you want to build an entire site, I'd recommend using one.
From a Pythonic point of view, you'd absolutely want to use one of the frameworks. Yes, it might be possible to write a web app without them, but it's not going to be pretty. Here's a few things you'll (probably) end up writing from scratch:
Templating: unless you're writing a really really quick hack, you don't want to be generating all of your HTML within your Python code -- this is a really poor design that becomes a maintainability nightmare.
URL Processing: splitting a URL and identifying which code to run isn't a trivial task. Django (for example) provides a fantastic mechanism to map from a set of regular expressions to a set of view functions.
Authentication: rolling your own login/logout/session management code is a pain, especially when there's already pre-written (and tested) code available
Error handling: frameworks already have a good mechanism in place to a) help you debug your app, and b) help redirect to proper 404 and 500 pages.
To add to this, all of the framework libraries are all heavily tested (and fire tested). Additionally, there are communities of people who are developing using the same code base, so if you have any questions, you can probably find help.
In summary, you don't have to, but unless your project is "a new web framework", you're probably better off using one of the existing ones instead.
Framework? Heck, you don't even need a web server if you're using Python, you can make one in around three lines of code.
As to the why:
The most plausible thing I can think of is that Perl and PHP were developed before the notion of using frameworks for web apps became popular. Hence, the "old" way of doing things has stuck around in those cultures. Ruby and Python became popular after frameworks became popular, hence they developed together. If your language has a good framework (or more than one) that's well supported by the community, there's not much reason to try to write a Web App without one.
A framework isn't necessary per se, but it can certainly speed development and help you write "better" code. In PHP, there are definitely frameworks that get used like CakePHP, and in Perl there are many as well like Mason and Catalyst.
The frameworks aren't necessary. However, a lot of developers think frameworks ease development by automating a lot of things. For example, Django will create a production-ready backend for you based on your database structure. It also has lets you incorporate various plugins if you choose. I don't know too much about Rails or Perl frameworks, but PHP frameworks such as Zend, Symfony, Code Igniter, CakePHP, etc are used widely.
Where I work at we rolled our own PHP framework.
Are these frameworks necessary?
No. They, like any 'framework', are simply for speeding up development time and making the programmer's job easier.
If not, is there a reason why these languages are often used within a framework, while Perl and PHP are not?
PHP and Perl were popular languages for building web sites well before the idea of using frameworks was. Frameworks like Rails are what gave Ruby it's following. I'm not sure that Python or Ruby were that common as web languages before they were backed by frameworks.
These days, even PHP/Perl web developement should be backed by a framework (of which there are now many).
By no means are those development frameworks required. But as with most development environments, your productivity will increase exponentially if you have a supported framework to reference and build your applications on. It also decreases the training needed to bring others up to speed on your applications if they already have a core understanding of the framework that you use.
For python, the answer is No you don't have to. You can write python directly behind your web server very easily, take a look at mod_python for how to do it.
A lot of people like frameworks because they supply a lot of the boilerplate code in a reliable form so you don't have to write it yourself. But, like any code project, you should choose the tools and frameworks on their merit for your problem.
You can certainly write CGI scripts in either language and do things "raw".
The frameworks (ideally) save the trouble of writing a pile of code for things that other people have already handled (session handling, etc.).
The decision probably comes down to what you need to do. If the framework has the features you need, why not use it. If the framework is going to require extensive modifications, it might be easier to roll your own stuff. Or check out a different framework.
The python library has numerous modules for doing cgi, parsing html, cookies, WSGI, etc:
http://docs.python.org/library/index.html
PHP has a lot of frameworks. Probably more then most. In Ruby most use Rails so thats what you hear, and Django for Python is mentioned more then not.
But with PHP you have many to choose from.
List of web application frameworks
Any language that can "print" can be used to generate web pages, but frameworks handle a lot of the HTML generation for you. They let you concentrate more on the content and less on the details of coding the raw HTML.
Every example I've seen of CGI/Perl basically a bunch of print statements containing HTML, and this doesn't seem like the best way to write a CGI app. Is there a better way to do this? Thanks.
EDIT: I've decided to use CGI::Application and HTML::Template, and use the following tutorial: http://docs.google.com/View?docid=dd363fg9_77gb4hdh7b. Thanks!
Absolutely (you're probably looking at tutorials from the 90s). You'll want to pick a framework. In Perl-land these are the most popular choices:
CGI::Application - very lightweight with lots of community plugins
Catalyst - heavier with more bells and whistles
Jifty - more magical than the above
This is a really, really big question. In short, the better way is called Model/View/Controller (aka MVC). With MVC, your application is split into three pieces.
The Model is your data and business logic. It's the stuff that makes up the core of your application.
The View is the code for presenting things to the user. In a web application, this will typically be some sort of templating system, but it could also be a PDF or Excel spreadsheet. Basically, it's the output.
Finally, you have the Controller. This is responsible for putting the Model and View together. It takes a user's request, gets the relevant model objects, and calls the appropriate view.
mpeters already mentioned several MVC frameworks for Perl. You'll also want to pick a templating engine. The two most popular are Template Toolkit and Mason.
Leaving the question of CGI vs MVC framework for the moment, what you're going to want is one of the output templating modules from the CPAN.
The Template Toolkit is very popular (Template.pm on CPAN)
Also popular are Text::Template, HTML::Template, and HTML::Mason.
HTML::Mason is much more than a template module, and as such might be a little too heavy for a simple CGI app, but is worth investigating a little while you're deciding which would be best for you.
Text::Template is reasonably simple, and uses Perl inside the templates, so you can loop over data and perform display logic in Perl. This is seen as both a pro and con by people.
HTML::Template is also small and simple. It implements its own small set of tags for if/then/else processing, variable setting, and looping. That's it. This is seen as both a pro and a con for the exact opposite reasons as Text::Template.
Template toolkit (TT) implements a very large, perlish template language that includes looping and logic, and much more.
I used HTML::Template one, and found I wanted a few more features. I then used Text::Template with success, but found its desire to twiddle with namespaces to be a little annoying. I've come to know and love Template Toolkit. For me it just feels right.
Your mileage may vary.
Of course, there is still the old "print HTML" method, sometimes a couple of print statements suffices. But you've hit upon the idea of separating your display from your main logic. Which is a good thing.
It's the first step down the road to Model/View/Controller (MVC) in which you keep separate your data model&business logic (your code that accepts the input, does something with it, and decides what needs to be output), your your input/output (Templates or print statements - HTML, PDF, etc.) , and the code that connects the two (CGI, CGI::Application, Catalyst MVC Framework, etc.). The idea being that a change to your data structure (in the Model) should not require changes to your output routines (View).
The Perl5 Wiki provides a good (though not yet complete) list of web frameworks & templates.
The comparison articles linked in the "templates" wiki entry is worth reading. I would also recommend reading this push style templating systems article on PerlMonks.
For templating then Template Toolkit is the one I've used most and can highly recommend it. There is also an O'Reilly book and is probably the most used template system in the Perl kingdom (inside or outside of web frameworks).
Another approach which I've been drawn more and more to is non template "builder" solutions. Modules like Template::Declare & HTML::AsSubs fit this bill.
One solution that I feel strikes the right balance in the Framework/Roll-your-own dilemma is the use of three key perl modules: CGI.pm, Template Toolkit , and DBI. With these three modules you can do elegant MVC programming that is easy to write and to maintain.
All three modules are very flexible with Template Toolkit (TT) allowing you to output data in html, XML, or even pdf if you need to. You can also include perl logic in TT, even add your database interface there. This makes your CGI scripts very small and easy to maintain, especially when you use the "standard" pragma.
It also allows you to put JavaScript and AJAXy stuff in the template itself which mimics the separation between client and server.
These three modules are among the most popular on CPAN, have excellent documentation and a broad user base. Plus developing with these means you can rather quickly move to mod_perl once you have prototyped your code giving you a quick transition to Apache's embedded perl environment.
All in all a compact yet flexible toolset.
You can also separate presentation out from code and just use a templating system without needing to bring in all the overhead of a full-blown framework. Template Toolkit can be used by itself in this fashion, as can Mason, although I tend to consider it to be more of a framework disguised as a templating system.
If you're really gung-ho about separating code from presentation, though, be aware that TT and Mason both allow (or even encourage, depending on which docs you read) executable code to be embedded in the templates. Personally, I feel that embedding code in your HTML is no better than embedding HTML in your code, so I tend to opt for HTML::Template.