Raphael Mankin wrote:
The problem here is not with the ORM but rather that you are breaking the MVC separation and putting controller logic in the view. A good ORM would have its data cached so that your test might not require two SQL queries. However, the template is, in this instance, the wrong place to put the test.
I disagree. In fact, I think you may have fallen into the MVC Silver Bullet[*] trap. There are many different kinds of logic in a web, including application (business) logic, web framework logic (e.g. routing requests and responses to and from handlers), access logic (authorisation and authentication), data logic (both internal ORM mapping and external entity modeling) and presentation (view) logic. Each has its own place, and the place for presentation logic is in templates. [% # display custom panel based on user status IF user.is_admin; INCLUDE admin/controls; ELSIF user.is_logged_in; INCLUDE user/greeting; ELSE; INCLUDE user/login; END; %] It is not up to the framework, the application, the controller or the ORM to decide how this information should be presented to the user. This is the domain of the web designer / information architect / usability consultant and the templates are their playground. It is the responsibility of the ORM to make a user look like a black box object that has an is_admin method that will tell anyone who asks of it if this user is an administrator. It is the responsibility of the web framework controller to map the request for this page to the appropriate handler, and to perform any additional authentication/authorisation/setup It is the responsibility of the application handler to ask the ORM to fetch a user object for the current user, and perform any other operations relevant to the task at hand. Then it hands those objects over to the template (or some other front-end presentation mechanism) along with any other information it needs to render the outcome to the user in whatever manner it deems appropriate. These are all separate responsibilities and should be treated as such. If you lump all the different kinds of application logic into one monolithic "all logic is controller logic" category then you end up with bloated controllers and a much weaker separation of concerns. A * http://wardley.org/computers/web/mvc.html