Re: Are there performance overheads to RequestAction?

[Felix Geisendörfer]

One thing about your change to my code example gwoo: Maybe I'm missing something, but here is what I think. -> Your solution does better for the requestAction without view scenario However, what I was talking about, was to *remove* a requestAction call for the menu and move it to the AppController. And in this scenario I see no reason why I shouldn't declare the Model in var $uses. Because if I don't, I create 2 Model instances for every controller request that needs to work with the Menu Model itself. For that reason defining $uses makes sure only one instance is created, no matter what. And since you already pointed out that Model's are the bottleneck in most App's, this is where you should start optimization. Now when requestAction without a view is called for some other controller, the Menu Model will still be instanced and queried for no reason in my solution. This is what your example tried to optimize. But I think this can be avoided by keeping an array() of action's which are used with requestAction, and simply see if one of those was called to decide weather to use the Menu Model or not. Now this isn't quite exactly comfortable, but we talk optimization right now, not comfort ; ). Since I completely stopped using requestAction in SpliceIt! due to it's massive problems with plugins, it's lag of error handling and my performance concerns about it, I can completely rely on beforeFilter solutions, like the one I proposed earlier, without worrying to much. Another thing is that I'm not really happy about, is using requestAction within views to retrieve data. From my understanding of MVC (which is limited I have to admit), views should not handle business logic, like data requests. That's the job of controllers not views. Requesting a rendered view with requestAction is ok, because the view stays clean from (most) business logic. But requesting data with requestAction reminds of people asking if they should $this->controller->{Model}->findAll() in there views. And if I recall right, this has never been a good strategy. But maybe it's not quite the same? Again, maybe I'm missing something, so just take this for what it is, my opinion ; ). Best Regards, Felix Geisendörfer -------------------------- http://www.thinkingphp.org http://www.fg-webdesign.de gwoo schrieb: There are a couple of things to keep in mind in this discussion. First, if you use full page caching putting a requestAction in and element that called a menu controller would be better. You can always use <cake:nocache>dont cache this </cake:nocache> Also, as of version 1.2 you will be able to specifically cache certain elements. However its also possible to do this in app controller as Felix suggests but I would write it like this: class AppController extends Controller { var $useMenu = true; function beforeRender() { if($this->useMenu) { $Menu = & new Menu(); $menuArray = $Menu->findAllThreaded(null, null, array ('position' => 'ASC', 'id' => 'ASC')); } else { $menuArray = null; } $this->set('menu', $menuArray); } } Using the beforeRender method is a better place in case you use requestAction to not return a view. As was previously stated requestAction is not much slower when it does not have to return a view. So, if you are using it in an element to just get the data needed you will not notice much of a speed difference over the above code. The slowest part of Cake is the model as in any application. View is the next slowest piece. The dispatcher and controller operate much faster. Bake on. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~----------~----~----~----~------~----~------~--~---