Once you have started rendering components you hit the class of problem you are referring to. Another similar issue is that you might only determine (& flag) form problems in the component that defines that actual form (nice encapsulation), but then you're past the point where you could display an error summary at the top of the page (eg. "please review the 3 errors below).
So as well as keeping logic and display seperate, I aim to have all the logic executed before any rendering commences - that way all parts of the page render have access to (or can be influenced by) all of the application logic.
This approach can save you from a whole class of tricky situations which mason alone doesn't really solve. Mason is really powerful for templating, includes, managing the interaction with mod_perl/apache etc. What it doesn't give you is an application framework.
I coded my own, for various reasons, along the lines described above. You can get basically the same effect with MasonX::WebApp for free from CPAN! The subtitle in the POD is "Works with Mason to do processing before Mason is invoked" which is a quick way of saying what I've been waffling on and trying to explain in these replies :)
In reply to Re: Seperating logic from web display using mason
by aufflick
in thread Problem with Mason, can it be solved with a subrequest?
by EvanCarroll
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |