This is the problem that I see with a templating only solution. Ie. all your logic is interleaved with the display and sometimes you figure things out too late.

This answer is, I admit, not so much a solution to your current problem, but rather a (very) different way of designing your web app that stops this being an issue.

The way I do it with perl/mason (which is not necessarily the best way) is to have a two pass apporach to every page. I borrowed this idea from the AOLServer templating system (and others) where you have a seperate template and code page.

In essence, each web request to one of my systems first runs a logic script (actually it instantiates an object of the right class, but you don't have to use OO) and then renders a template.

This may not be clear, so lets take an example:

  1. Someone requests mysite.com/foo/bar
  2. my custom request processor code (which could be run by the mason_handler or the autohandler or a dhandler, depending on your setup) determines that it should instantiate an object of type My::Site::Web::foo::bar
  3. After successful instantiation, it passes the %ARGS from any form post into a method called (by convention) run_page which implements all the non-display logic for that page. The convenience here of using OO is that this method can be subclassed to allow sharing of common page tasks like security management etc.
  4. Note that the object is also passed (or has access to a global) variable %session or similar, to access a session hash managed by Apache::Session
  5. If run_page returns true, then the request processor renders the web page with the mason component /foo/bar
  6. The mason component has access to both the %session hash, but also to another mason global that I name $page which is (in this case) the My::Site::Web::foo::bar object
That is the way a normal page render works. In the case where, say, an error occurs or someone is lacking the required permissions, then the request processor can instead render (or redirect to) a different template eg. an error page.

There are a lot more subtleties to my actual implementation (which I hope to be able to release to CPAN with the appropriate authorisation), but the basic idea of processing logic first, and rendering the template second is relatively easy to implement using mason, and gives you a lot more power in situations like this.

I know that mason has it's own way of allowing method calls within the mason framework, but I believe it was Randall Scwhartz (or possibly Ken Williams) who said (on the mason mailing list) something like "if something can be done in a perl module, it probably should".

In reply to Seperating logic from web display using mason by aufflick
in thread Problem with Mason, can it be solved with a subrequest? by EvanCarroll

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.