Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: More on Web Application Frameworks

by Tardis (Pilgrim)
on Apr 09, 2002 at 01:19 UTC ( #157624=note: print w/replies, xml ) Need Help??

in reply to More on Web Application Frameworks

Although I have only so far used it in a limited fashion, Mason appears very powerful. It does use mod_perl, but can work without it (with the appropriate speed penalty).

Within a couple of hours I put together a basic web site that had automatic templates, dynamic sidebar menu, and so on.

Replies are listed 'Best First'.
Re: Re: More on Web Application Frameworks
by impossiblerobot (Deacon) on Apr 09, 2002 at 03:17 UTC
    Thanks, Tardis. Have you had a chance to use Mason in CGI mode? I wonder how much of a speed hit there would be. I wouldn't expect a lot of traffic for this application, but I also don't expect it to be running on very fast servers.

    Also, how well does Mason match up with my needs/preferences? Do its tools work well when not used in an embedded-code type application (which I understand is the normal way to use Mason)?

    Impossible Robot
      I'd prefer not to comment directly, given I haven't used it that much. I can tell you what I have done though.

      Page templating is done via the autohandler. The autohandler gets called for all page requests, plus it is also done in a hierarchy - if the current directory doesn't have an autohandler, it will go up a level and try the parent. As you can imagine, this makes page templating with overrides for certain web site areas rather easy.

      After my autohandler has done the page setup (via broken out components, my autohandler has very little actual HTML in it), I have a line: <% $m->call_next %>. This is where whatever actual object was referenced in the URL starts being displayed/processed.

      Thus, my actual documents have very little in them except basic markup. There is no need to have includes for the headers or footers, it's done automatically. I do have:

      <%method title>Page title here</%method>
      Which propagates up the tree, and is available to my components that generate the actual page headers and so forth.

      What I haven't done yet, is any form of user interactivity, though it looks like it will be quite easy handling GET/POST requests. But so no more, since I haven't tried it yet.

      Also of note (though I haven't used it yet either) is the caching ability - components can be automatically cached, and only regenerated after certain times. For example, a weather component might generate a chunk of HTML which shows the current temperature. The caching can easily ensure that it only runs say once per hour, calling components receiving the cached output in the meantime. This is a big boon for performance. I'm not sure if this works in non-persisitant (ie non mod_perl) environments.

      Lastly, and perhaps most importantly, there is very good documentation available on the web site, and some good tutorials around on other sites as well.

      BTW, I probably haven't explained the Mason stuff above too well, Mason diehards are welcome to go postal on any mis-uses of Mason terminology above :-).

      I use Mason a lot. Mostly on a mod_perl server. It can run, a bit slowly, in cgi mode. You can also run with FastCGI, although you lose some mod_perl based functionality.

      Mason has a pretty high overhead in CGI-mode, because you'll need to load the interpreter, handler, and parser objects, and then load your component and any modules used by any of these pieces for every page view. Speed is acceptable if you have very low traffic. Any persistance framework (ISAPI, mod_perl, etc.) will help a lot.

      There is an excellent article on masonhq called Design Issues with Mason. It should answer your question about not using embedded code. You can also use components in a MVC style--some components are used for display, some for app logic, and some for data access. Whichever style you use, mason's embedded code capability makes creating working prototype applications incredibly fast and easy.

      Probably the coolest thing about Mason is it's parameter handling. You have THREE different ways of getting params, and it can be useful to mix them. You can declare an <%args> section in your component, and name your variables:

      <%args> $foo => 'FOO!' # the value of foo goes here, default value "FOO!" @bar # Here we ask for a list of bar values, no default means bar is +a required param. $dog => $foo.'dog' # You can have dynamic defaults. $cat => undef # or undef by default. </%args>

      You can also just pull things out of @_, just like a perl subroutine, which is actually what a mason component compiles into. And third, you can use the magnificent %ARGS hash. This is really handy for building components that print form data in a pretty way without having to hard code in fields:

      <HTML><head><title>STUFF</title></head> <body> <table> % foreach my $field ( keys %fieldSpecs ) { <tr><td><% $field %></td><td><% $ARGS{$field} %></td></tr> % } </table> </body> </HTML> <%args> %fieldSpecs </%args>

      Of course a real usage of the above would need to be a bit more complex. You can manipulate one structure without affecting the others. This has proven to be rather handy.

      Dhandlers, autohandlers and inheritance are also very cool mason features. Autohandlers provide a way of creating nested templates and core functionality common to entire hierarchies on your server. If you have a file at /home/html/foo/bar/baz.html, it will automatically invoke the autohandlers at /home/html/autohandler (I'm assuming /home/html/is you doc root), /home/html/foo/autohandler, /home/html/foo/bar/autohandler. Combined with inheritance we have a very powerful feature. You can create sub components that live inside a main, parent component, if you specify that they are 'method's they can then be inherited. For example if you want every component on your website to be able to find print the time in roman numerals, you write a method to do this, then stick it in your root authandler. Then in any component you can call $m->comp(SELF:RomanTime) to get the results. Dhandlers allow you to specify how to react to requests for files that don't exist. Say you have all your content in xml stored in a database. You can write a dhandler that translates an html document request into a call to routines that look up the appropriate xml in the db, transform it to html. Your autohandler will take care of wrapping it in your standard templates for you.

      That's my Mason is Cool rant. I hope you have found it useful. Check out Bricolage and RT, a couple of impressive Mason apps. Plus, VIm has a syntax definition for Mason.

      TGI says moo

        Thanks, TGI. This is exactly the kind of feedback I'm looking for. I definitely lean toward the MVC structure, and if Mason can make that easier than other tools, then it is on my list of possible solutions. I will definitely check out the article you mentioned. I'll probably need to do some speed testing myself, to see if Mason will be acceptable in CGI mode, though I hope I won't have to go that route.

        Impossible Robot

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://157624]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2018-06-19 01:27 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (111 votes). Check out past polls.