> > But I don't want to be constrained by the Framework, on the contrary.... >
Then don't be. So long as you understand what the 'issues' are with a framework then they can be worked around (in an afterFind() for example). Your example (better known as a correlated subquery) will never be particularly performant because each subquery has to be executed once for each row the parent returns. Yes, a view is likely to be faster (and it would also be my first choice too) but the example statement as a plain query would also know the constants (that are usually evaluated early) so there could be benefits there. The biggest obstacle to performance is the statement you're executing, not whether it is a view or a plain query. Cake provides the framework for the vast majority of your transaction processing (the 80:20 rule), but it much, much more than ORM.There is no reason you can't have dedicated 'view' models for complex situations like the above. The business logic is still encapsulated in one place. Create the view queries in the model and call them via a dedicated method (e.g. model->findQtyOnHand() etc.). > .... And I want a framework to not have to reinvent the wheel when > I need users to login, for example. > Bernard Take a look at the Components on the Bakery. If they don't meet your needs (every requirement is different, so don't be surprised if they don't) it is trivial to stand on the shoulders of giants and modify one to suit your needs. ~GreyCells --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
