Yes, another layer... seems a bit crazy. It looks like their may be
more bits and pieces of unique code sprinkled into your pages than I
imagined. None the less, a couple more thoughts?
- A new route could override the basic controller/action/params
pattern and funnel everything to your accumulator controller/action
while still passing along the controller/action/params that are needed
to fully inform the process.
- Or maybe your component just needs to be extended a bit to do the
necessary additional portioning-out of tasks
Either way seems in line with cake philosophy.
- I've had some success with shipping html into php's XML/DOM
manipulators (http://us.php.net/manual/en/refs.xml.php
http://us.php.net/manual/en/domdocument.loadhtml.php) and that has
sometimes made it very easy to swap an entire div in or out of a page.
It's also given me ways of walking through the DOM in php to make all
sorts of fussy page tweaks. This just moves the javascripty way
manipulating pages into your component, action or helper.
- Possibly a final helper could be fed the cached and dynamic chunks
for assembly into your final cach-namic page. That would be a pretty
cake-y way to go.
I'm excited about this plan! Especially since I don't have to write
it!
Don
On May 31, 8:54 am, Jeremy Burns | Class Outfit
<jeremybu...@classoutfit.com> wrote:
> Hmmm...nice thinking and I appreciate your reply, but it sounds like it's derailing Cake somehow. This happens on every page view so I'd effectively be putting another layer in there.
>
> A bit more background...
>
> The component scans $this->params and takes into account a number of factors like is the user logged in, are they an administrator, do they perform some other sort of role, where are they in the system, what menu items should have the 'selected' class and so on. It produces a keyed array (e.g. main, sub-1, sub-2, user [log in/log out/logged in as etc] and so on). The array is passed to the view as a variable. The default.ctp layout contains an element that parses each key and renders output.
>
> Currently it's called in app_controller/beforeRender() but this is now being bypassed when the view is cached. It is, by it's nature, very dynamic. It can't easily be created in full in advance and placed in session because, for example, a user could log in and then log out.
>
> Jeremy Burns
> Class Outfit
>
> jeremybu...@classoutfit.com
> (t) +44 (0) 208 123 3822
> (m) +44 (0) 7973 481949
> Skype: jeremy_burnshttp://www.classoutfit.com
>
> On 31 May 2011, at 15:58, dreamingmind wrote:
>
>
>
>
>
>
>
> > Jeremy,
>
> > I don't know details of how to accomplish this, but it seems like
> > you're going to have to call another non-cached action instead of the
> > action you want. It will:
>
> > - call the navigation engine to get an html fragment of your menus
> > - call the desired action and get the page rendering
> > - plug the menus into the page and send it to the browser
>
> > or
>
> > - send the menu out as a string that javascript can insert in the page
> > once it loads
>
> > Does this seem possible?
>
> > Regards,
> > Don
>
> > On May 31, 5:44 am, Jeremy Burns <jeremybu...@classoutfit.com> wrote:
> >> I've raised a similar question before but got no responses, so I'll
> >> try something more specific.
>
> >> I have an application that is pretty dynamic. With no caching turned
> >> on there is a lag of around 2 seconds before anything happens, and
> >> then it all zips in really quickly. If I blanket enable view caching
> >> (enabling cache in core.php, adding the Cache helper to app_controller
> >> and setting cacheAction to +1hour) the lag disappears, response is
> >> fantastic but the results are (understandably) terrible as nothing is
> >> dynamic.
>
> >> If I move the cache setting from app_controller into specific actions
> >> I start to get better results. It's a pretty big app, so that's going
> >> to take a lot of time and testing to do correctly. However, I have a
> >> particular problem that I need to solve before I put in the effort.
>
> >> I have a navigation component that reads $this->params, sets up some
> >> variables that are passed through the controller and rendered in an
> >> element (that also has a nested element):
>
> >> function beforeRender() {
> >> $this->set('menus', $this->Navigation->menus($this->params));
>
> >> I have placed <cake:nocache></cake:nocache> blocks in the elements.
>
> >> Reading the Cake on line book:
> >> "It should be noted that once an action is cached, the controller
> >> method for the action will not be called - otherwise what would be the
> >> point of caching the page. Therefore, it is not possible to wrap
> >> <cake:nocache> </cake:nocache> around variables which are set from the
> >> controller as they will be null."
>
> >> As every page contains the navigation code, it would seem that I
> >> cannot pass the menus variable down. Subsequent rendering of the
> >> navigation (when the contents have changed) delivers lots of
> >> 'Undefined index' errors as the variables are indeed missing. This is
> >> especially so when a user logs in and then logs, which generates
> >> different menu content.
>
> >> Can anyone suggest a work around for this?
>
> > --
> > Our newest site for the community: CakePHP Video Tutorialshttp://tv.cakephp.org
> > Check out the new CakePHP Questions sitehttp://ask.cakephp.organd help others with their CakePHP related questions.
>
> > To unsubscribe from this group, send email to
> > cake-php+unsubscribe@googlegroups.com For more options, visit this group athttp://groups.google.com/group/cake-php
--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
No comments:
Post a Comment