Re: Are there performance overheads to RequestAction?
Hi.
This thread is being very enlightening. I have a question though: doesn't
an action always render a view (unless $autoRender is set to false)? Here's
an example:
in one_controller.php:
function foo()
{
$this-set('foo', $this-Foo-findAll());
$this-render('foo_view');
}
*NOTE*: The render() part is optional, of course, but assuming $autoRender
is not set to false it will implicitly render foo.thtml.
in other_controller.php:
function bar()
{
$this-set('bar', $this-Bar-findAll());
$this-set('foo', $this-requestAction('/one/foo'));
}
Maybe i'm missing something but doesn't the call to '/one/foo' always
render the view, even though requestAction is not asked to return the
rendered view? Does foo()'s implementation have to contemplate the two
distinct situations? Kinda like:
function foo()
{
$foo = $this-Foo-findAll();
if ($this-isCalledByRequestAction) {
return $foo;
}
else {
$this-render('foo_view');
}
}
Thanks in advance.
--
Gonçalo Marrafa [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
if ($this-isCalledByRequestAction) {
if (!empty($this-params['bare']))
But be careful, 'bare' parameter is 1 in case of ajax call also
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
I'm also dreaming of a
$this-isCalledByRequestAction
I made a ticket for this https://trac.cakephp.org/ticket/1013
olivvv
Gonçalo Marrafa wrote:
Hi.
This thread is being very enlightening. I have a question though: doesn't
an action always render a view (unless $autoRender is set to false)? Here's
an example:
in one_controller.php:
function foo()
{
$this-set('foo', $this-Foo-findAll());
$this-render('foo_view');
}
*NOTE*: The render() part is optional, of course, but assuming $autoRender
is not set to false it will implicitly render foo.thtml.
in other_controller.php:
function bar()
{
$this-set('bar', $this-Bar-findAll());
$this-set('foo', $this-requestAction('/one/foo'));
}
Maybe i'm missing something but doesn't the call to '/one/foo' always
render the view, even though requestAction is not asked to return the
rendered view? Does foo()'s implementation have to contemplate the two
distinct situations? Kinda like:
function foo()
{
$foo = $this-Foo-findAll();
if ($this-isCalledByRequestAction) {
return $foo;
}
else {
$this-render('foo_view');
}
}
Thanks in advance.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
I would really like to see my original question answered. Doesn't the view get rendered with requestAction(), even if the 'return' parameter isn't passed? Master bakers, can you enlighten us? Thanks in advance. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
Yes if you put $this-render() in the method. As was discussed the
really should not be needed and a simple return is preferred.
function foo(){
return $this-Example-findAll();
}
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
On Fri, 30 Jun 2006 10:19:42 -0700
gwoo [EMAIL PROTECTED] wrote:
Yes if you put $this-render() in the method. As was discussed the
really should not be needed and a simple return is preferred.
function foo(){
return $this-Example-findAll();
}
OK, but doesn't work for me. I have actions that render different views
according to conditions so i have to use redner(). I think there should be
a parameter indicating if the request was made through requestAction().
--
Gonçalo Marrafa [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
Thanks Felix, That's great info - I actually had bookmarked your blog post in my feeds to read later - wasn't sinking in when I tried reading it before - so I'll take a closer look now. all the best, -ad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
Hi! I am also using actionRequest to render several different controllers from within a main controller and I have noticed that the dispatcher is called for each call to a controller. I haven't done any real testing yet so I'm not sure about the performance. Is there a way to reuse the Dispatcher and Controller for several user controllers and plugins? I'm also thinking about extending the Dispatcher or the Controller with a class that should be globally accessible by the user controllers and views. Any comments on that? At the moment I am experimenting with creating a private singleton class in the AppController that is extended by public accessible classes such as Request, Response, Security etc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
It depends on way how You're using requestAction().
If You're using it like:
$this-requestAction('/some/url');
or
$somedata = $this-requestAction('/some/url');
then it is supposed to be quite fast, as target controller's action is
not rendered. Off course there is new dispatch process for every such a
call, but it is cool, because You can use routed-url's and passing
parameters like requestAction('/url',
array('myParamName'='myParamValue')) with requestAction() also.
BUT: if You're using it like
$renderedView = $this-requestAction('/some/url', array('return'));
(so You will obtain rendered view content), then targetted controller's
action is rendered, so extra instance of View class is created for it,
there is used output buffer and if You're using rendering by
requestAction() often in during of one request, Your page generation
time will slow down a little bit - 'how big bit' depends on many
factors.
I was talking about same thing some time ago at IRC with one of core
devs and his propose to me was: use requestAction() for obtaining data
and pass them to renderElement() method - so all render-actions will be
maked in lifetime of one View instance.
I hope it makes sense, I speak English like Tarzan.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
Hi johnwik, I think the problem with requestAction is not the dispatching alone. There is a good bit of things happening, just to name a view: Dispatcher Dispatcher does routing Dispatcher figures out what (Plugin)/Controller/Action is request Dispatcher loops through all $paths-controllerPaths files, to figure out what Controller to load (if you request one you haven't requested before) Comment: None of this is necessary when you use requestAction. You know what exact controller/action you need. No request-php interface for this is needed recursive functions get called twice (stripslashes_deep, see Dispatcher::parseParams() ) Lot's of regex get's executed again (finding webroot, base, etc.) Comment: Some of this stuff is necessary to parse the params correctly, but most of it is overhead you only need when rendering the first Controller action in your script execution. Controller setup Once the dispatcher has figured out what Controller you want to use, the following things get executed over and over again for every requestAction, even if you call the same controller again. All Controller Models get loaded and referenced as Controller variables (Note: I think the ClassRegistry keeps record of previously created class instances, which is good) All Components get re-instanced over and over again All filter's (before, after, beforeRender) get executed Comment: I think for a good deal of things requestAction is beeing used right now, some of the stuff above in unnecessary, however avoiding some of it by default could lead to confusion and strange behavior. So I'm not trying to say that requestAction should be avoided, nor that it is bad. But I think doing a fair performance test on it, vs. other approaches would be hard to setup because it's difficult to say what of the stuff above is definitely unnecessary and what isn't. And depending on this decision results could be pretty different. Side Note: I've written the stuff above from my understand of the dispatching process and only looked in the core code a couple times, so some of it might not be completely correct. My advice to people who are concerned about performance, is to think about what they are using requestAction for right now, and to try to figure out if some of it should be moved to the AppController. This will always be the better and faster solution if you have something like a menu, that you need to have rendered for every request. At least it is to me. I think requestAction is more of a problem when you are working with plugins that are supposed to be independent from the AppController setup like I do. Because in that case you might end up with something like 15-20 requestActions / execution which is definitely too much overhead for me. Right now I'm running with my own solution for the problem which I mentioned in my earlier post, but I definitely want to talk to one of the devs about it when I (and they) find time to. Anyway, I hope that stuff above is useful when you try to get your own idea about the overhead caused by requestAction. Best Regards, Felix Geisendörfer -- http://www.thinkingphp.org http://www.fg-webdesign.de johnwik schrieb: Hi! I am also using actionRequest to render several different controllers from within a main controller and I have noticed that the dispatcher is called for each call to a controller. I haven't done any real testing yet so I'm not sure about the performance. Is there a way to reuse the Dispatcher and Controller for several user controllers and plugins? I'm also thinking about extending the Dispatcher or the Controller with a class that should be globally accessible by the user controllers and views. Any comments on that? At the moment I am experimenting with creating a private singleton class in the AppController that is extended by public accessible classes such as Request, Response, Security etc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
Ok, between this, the wiki and manual things are getting tasty and I
think I'm understanding how to bake better cake... thanks all for the
discussion and feedback.
Previously I was using requestAction to return rendered views from
foreign controllers, by using it in my elements or directly in the
layout. Apparantly that's what can lead to the overheads associated
with requestAction()
So to avoid rendering the view more than necessary I've altered my
strategy, and the controller methods I'm calling with requestAction
return an array , which I am passing to an element (via renderElement)
which handles the rendering of the view.
From my understanding of this discussion, the following is an example
of the more efficient way to use requestAction. I'm aiming to include a
list of events on an articles/view page.
It works, but does this look like the right setup for Cake best
practices?
1. In controllers/events_controller.php:
function eventslist(){
return $this-Event-findAll() //returns an array of events
}
2. In views/elements/eventslist.thtml:
- foreach loop to render the list
3. In controllers/articles_controller.php:
function view(){
[...article view stuff...]
$this-set(eventslist,
$this-requestAction(/events/eventslist));
}
4. In views/articles/view.thtml:
echo $this-renderElement(eventslist,$eventslist);
-ad
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
Hi felix " My advice to people who are concerned about performance, is to think about what they are using requestAction for right now, and to try to figure out if some of it should be moved to the AppController. This will always be the better and faster solution if you have something like a menu, that you need to have rendered for every request" how are you doing that ? currently I have menus that are in every page, and I use requestAction in the layout to do that. olivvv Felix Geisendörfer wrote: Hi johnwik, I think the problem with requestAction is not the dispatching alone. There is a good bit of things happening, just to name a view: Dispatcher Dispatcher does routing Dispatcher figures out what (Plugin)/Controller/Action is request Dispatcher loops through all $paths-controllerPaths files, to figure out what Controller to load (if you request one you haven't requested before) Comment: None of this is necessary when you use requestAction. You know what exact controller/action you need. No request-php interface for this is needed recursive functions get called twice (stripslashes_deep, see Dispatcher::parseParams() ) Lot's of regex get's executed again (finding webroot, base, etc.) Comment: Some of this stuff is necessary to parse the params correctly, but most of it is overhead you only need when rendering the first Controller action in your script execution. Controller setup Once the dispatcher has figured out what Controller you want to use, the following things get executed over and over again for every requestAction, even if you call the same controller again. All Controller Models get loaded and referenced as Controller variables (Note: I think the ClassRegistry keeps record of previously created class instances, which is good) All Components get re-instanced over and over again All filter's (before, after, beforeRender) get executed Comment: I think for a good deal of things requestAction is beeing used right now, some of the stuff above in unnecessary, however avoiding some of it by default could lead to confusion and strange behavior. So I'm not trying to say that requestAction should be avoided, nor that it is bad. But I think doing a fair performance test on it, vs. other approaches would be hard to setup because it's difficult to say what of the stuff above is definitely unnecessary and what isn't. And depending on this decision results could be pretty different. Side Note: I've written the stuff above from my understand of the dispatching process and only looked in the core code a couple times, so some of it might not be completely correct. My advice to people who are concerned about performance, is to think about what they are using requestAction for right now, and to try to figure out if some of it should be moved to the AppController. This will always be the better and faster solution if you have something like a menu, that you need to have rendered for every request. At least it is to me. I think requestAction is more of a problem when you are working with plugins that are supposed to be independent from the AppController setup like I do. Because in that case you might end up with something like 15-20 requestActions / execution which is definitely too much overhead for me. Right now I'm running with my own solution for the problem which I mentioned in my earlier post, but I definitely want to talk to one of the devs about it when I (and they) find time to. Anyway, I hope that stuff above is useful when you try to get your own idea about the overhead caused by requestAction. Best Regards, Felix Geisendörfer -- http://www.thinkingphp.org http://www.fg-webdesign.de johnwik schrieb: Hi! I am also using actionRequest to render several different controllers from within a main controller and I have noticed that the dispatcher is called for each call to a controller. I haven't done any real testing yet so I'm not sure about the performance. Is there a way to reuse the Dispatcher and Controller for several user controllers and plugins? I'm also thinking about extending the Dispatcher or the Controller with a class that should be globally accessible by the user controllers and views. Any comments on that? At the moment I am experimenting with creating a private singleton class in the AppController that is extended by public accessible classes such as Request, Response, Security etc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
Hi olivvv:
I just modified the AppController from a project I work on right now to
only show the process of setting $menu in every view (unless you set
your controllers var $useMenu to false), so you can use it in your
layout without having to do requestActions:
class AppController extends Controller
{
var $useMenu = true;
function __construct()
{
if (empty($this-beforeFilter))
$this-beforeFilter = array();
if (empty($this-uses))
$this-uses = array();
if ($this-useMenu==true)
$this-uses[] = 'Menu';
$this-beforeFilter[] = '__AppBeforeFilter';
parent::__construct();
}
function __AppBeforeFilter()
{
// This is needed when an error like missingController get's rendered and you still want your Models to load!
if (!isset($this-Menu))
$this-constructClasses();
$this-set('menu', $this-Menu-findAllThreaded(null, null, array('position' = 'ASC', 'id' = 'ASC')));
}
}
I think it's pretty self-explanatory, otherwise just ask and I'll
explain a little further ; ).
Best Regards,
Felix Geisendörfer
--
http://www.thinkingphp.org
http://www.fg-webdesign.de
Olivier Percebois-Garve schrieb:
Hi felix
"
My advice to people who are concerned about performance, is to think
about what they are using requestAction for right now, and to try to
figure out if some of it should be moved to the AppController. This
will always be the better and faster solution if you have something
like a menu, that you need to have rendered for every request"
how are you doing that ? currently I have menus that are in every page,
and I use requestAction in the layout to do that.
olivvv
Felix Geisendörfer wrote:
Hi johnwik,
I think the problem with requestAction is not the dispatching alone.
There is a good bit of things happening, just to name a view:
Dispatcher
Dispatcher does routing
Dispatcher figures out what (Plugin)/Controller/Action is
request
Dispatcher loops through all $paths-controllerPaths
files,
to
figure out what Controller to load (if you request one you haven't
requested before)
Comment: None of this is necessary when you use
requestAction.
You know what exact controller/action you need. No request-php
interface for this is needed
recursive functions get called twice (stripslashes_deep, see
Dispatcher::parseParams() )
Lot's of regex get's executed again (finding webroot, base,
etc.)
Comment: Some of this stuff is necessary to parse the
params
correctly, but most of it is overhead you only need when rendering the
first Controller action in your script execution.
Controller setup
Once the dispatcher has figured out what Controller you want to use,
the following things get executed over and over again for every
requestAction, even if you call the same controller again.
All Controller Models get loaded and referenced as Controller
variables (Note: I think the ClassRegistry keeps record of previously
created class instances, which is good)
All Components get re-instanced over and over again
All filter's (before, after, beforeRender) get executed
Comment: I think for a good deal of things requestAction is
beeing used right now, some of the stuff above in unnecessary, however
avoiding some of it by default could lead to confusion and strange
behavior.
So I'm not trying to say that requestAction should be avoided, nor that
it is bad. But I think doing a fair performance test on it, vs. other
approaches would be hard to setup because it's difficult to say what of
the stuff above is definitely unnecessary and what isn't. And depending
on this decision results could be pretty different.
Side Note: I've written the stuff above from my understand
of
the dispatching process and only looked in the core code a couple
times, so some of it might not be completely correct.
My advice to people who are concerned about performance, is to think
about what they are using requestAction for right now, and to try to
figure out if some of it should be moved to the AppController. This
will always be the better and faster solution if you have something
like a menu, that you need to have rendered for every request. At least
it is to me.
I think requestAction is more of a problem when you are working with
plugins that are supposed to be independent from the AppController
setup like I do. Because in that case you might end up with something
like 15-20 requestActions / execution which is definitely too much
overhead for me. Right now I'm running with my own solution for the
problem which I mentioned in my earlier post, but I definitely want to
talk to one of the devs about it when I (and they) find time to.
Anyway, I hope that stuff
Re: Are there performance overheads to RequestAction?
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:nocachedont 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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
very useful explanations felix and gwoo. Thanks a lot, I'll sleep less
stupid tonight.
gwoo wrote:
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:nocachedont 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
-~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
unless you want the Menu model available in all of your controllers, I would not put it in the uses array. Both the uses array and the method I described use references, so they are pretty much the same in that respect. As far as MVC, requestAction in a view should be avoided. Elements break some of the MVC rules to make our lives easier, so lets not get too caught up there. Overall, Felix I think you are writing more code than you need to. A couple of things from my perspective. The beforeFilter property was deprecated in 0.10 in favor of the beforeFilter() method. The beforeFilter happens before the controller, so grabbing a menu for display is out of place there unless for some reason you need that menu data in all your controllers. 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 -~--~~~~--~~--~--~---
Re: Are there performance overheads to RequestAction?
Hey admataz, from my experience the performance overhead from requestAction can be significant when you have more then 5-7 of such calls for each action you execute. However, this definitely depends on the work-load that is caused by the actions/views themselfs, so I would need to do a series of benchmarks in order to figure out how much overhead is caused by requestAction itself. What I can tell you for sure, is that I've written up a solution for my plugin based cms(toolbox) called SpliceIt!, that has it's own way to exchange data between controllers and that performance increased by a good amount after implementing it. I basically added a new variable to my AppController that's called $apis (var $apis) and I can use it like var $models, but the stuff that get's loaded are specific Controllers of other plugins that are only ment for data exchange with other plugins, I call them ApiControllers. Just take a look at this, if you are interested in it: http://www.thinkingphp.org/2006/06/24/welcome-to-the-dark-side-of-plugins-in-cakephp/ right now it's still a bit experimental, but works like a charm. I would love to see a similar thing integrated into the cake core and I'll try to talk to phpnut_ about it, but I don't have too much hope that'll actually be part of cakephp soon ; ). Therefor, you should stay with requestAction and maybe make use of cache() as much as you can for right now. Best Regards, Felix Geisendörfer -- http://www.thinkingphp.org http://www.fg-webdesign.de admataz schrieb: Hi all, From some of the research I've done and few experiments I've tried with CakePHP, I've discovered that RequestAction in combination with Elements is an extremely useful and flexible way of embedding modular dynamic content on pages controllers. However, a few comments I have read in this list suggest there is an overhead and possible performance hit when using RequestAction. Can someone clarify or confirm? Thanks for all the tasty treats. CakePHP is really working well for me. -ad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
