|
|
|
| Perl Monk, Perl Meditation | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
The web page for C:A tells us that it is better than Mason because Mason creates lots of files.
The author of that text hasn't used Mason very much. If you wanted with Mason you could put all your components in one file using the inline component block - or you could just use one component and wite a great big MVC framework if you wanted to. I agree 100% with the author of the original comment. The problem with a lightweight MVC framework like C:A is: a) It often adds an extra layer (to be learned and more code to load) for very little obvious benefit. E.g. to use JSON there is a JSON plugin, but this is not much more than a wrapper around the JSON module. In as much as it is more it provides a mechanism for intercepting the output in your C:A application with a hook. My problem with this is if I wanted this kind of functionality I'd rather code it myself than learn how someone else has done it. b) Because it is lightweight your application will end up as a hybrid beteen C:A and your own systems e.g. I've had to develop a little component system because it doesn't really do components, being stuck in this Web 1 way of thinking where the whole page is served each time. But this is messy. There are two ways out of this: either use a framework which really does cover everything, like PHP's Symfony (if that's your bag), or don't use a framework at all. The MVC model is fine if appropriate: but most developers should have the discipline to separate out model view and controller without being put into a strait-jacket. Justin In reply to Why CGI::Application?
by kropotkin
|
|