Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I come at this from having paired Propel with symfony 1.0 for several years. Perhaps I've not understood your post fully, but I am unsure what you think is missing from Propel.</p> <p>For clarity, the thing you call a model, I would call "business logic" or an "action". The model, at least the way I understand the jargon, is the database and the class layer on top of the database. Your "views" are IMO still part of the logic/action section of MVC. I would regard a view as officially referring to something different: the output layer that renders the output of an action.</p> <p>In Propel, you basically have three classes for each table: row, peer, and query (historically Propel users have got used to two, since query is new). The row is simple - just a class representation of a database row. The peer is for table-wide operations such as selecting several rows, and the query class is a new chainable API to run statements on the database.</p> <p>So, in each of your actions (login, logout, etc) you should call Propel to do the necessary work. Where you find you have a large chunk of code in your action, in most cases it can be refactored into a Propel row or peer. This fits in with the MVC rule of thumb "thin controllers, fat models" i.e. try to keep your db stuff in the controller slim.</p> <p>How you should structure your project depends on your framework, but I would show it like this:</p> <pre><code> RegistrationController - which uses the UserAction - which in turn should call something like LoginAction (rendered by LoginView) LogoutAction (rendered by LogoutView) SignupAction (rendered by SignupView) ProfileAction (rendered by ProfileView) - each of which access the model UserModel </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload