in reply to Re: Template modules, logic, and SOC
in thread Template modules, logic, and SOC

...there's no good reason I can see to even try to "keep the code out of the view".

I think the usual reason is, "so they can be worked on separately." This is especially nice if you have dedicated designers doing HTML and CSS distinct from the people who work on Perl and SQL and JavaScript (oh my), but it's also nice for an individual who wants to be able to mutate things independently.

Replies are listed 'Best First'.
Re^3: Template modules, logic, and SOC
by Joost (Canon) on Jan 23, 2008 at 19:50 UTC
    Well, if you have an Object-Relational system like DBIx::Class, you should/will usually put all (or at least most) of the SQL needed in the model classes anyway. I very much prefer to make the model easy enough to use so that I can use it directly in the view.

    I have had doubts about the separation between front-end and back-end programmers for a long time. Especially for applications. JSP/PHP like templating works OK for things like CMS templates (provided you the model API is stable enough over updates) but they get seriously annoying when you're writing reusable widgets or heavily interactive applications.

    Anyway trying to keep a template system flexible enough to actually work, and still rigid enough that you can get any inexperienced HTML guy mess with it without potential consequences is futile. There will never be such a system. In the end the programmers will take your straight-forward page-by-page design and cut it up and break it apart anyway, just to get consistency.