NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
It's a different way, not a wrong way :) (Score:2)
You like URI based dispatching, but I hate that. Even then, it's not hard to do in CGIP. It's not like URIs are magic. Once the application gets control, they are just input data like anything else. CGIP gets rid of the idea of run states and lets you switch courses at several points. You're decoupled from the starting point.
I'm not sure what you mean about the poor separation of concerns. In CGIP you can build up the data anyway that you like as you go along. The View gets access to it all and can display it anyway that you like, including hooking back into the Model directly. It's very decoupled. Although CGIP uses Template by default, one of our clients replaced that with XML/XSLT without too much pain.
It sounds like you don't like that you had to make the decisions and do the work to make CGIP do exactly what you wanted. That is, however, the entire point. You might not *like* it, but don't confuse that with valid technical arguments.
Reply to This
Re: (Score:1)
It started as a reply to your post, yes. Then I realised it was beside the issue. Anyway, it is why I wouldn’t pick CGIP again.
They’re not, but CGIP scatters the responsibility for dispatch across all of your classes by way of the
respondmethod, and it will not invoke a method other thanrespondin the course of dispatch, nor does it provide a built-in mechanism of passing parameters to it. So you have to rig up the entire machinery to parse the URI and rRe: (Score:2)