Zikula Community

• espaan
  
  

  • Rank: Developer
  • Registered: Aug 23, 2003
  • Last visit: May 31, 2010
  • Posts: 1428

  Posted: Apr 20, 2011 - 09:43 AM

  So cache_id is most of the time necessary in modules and doing a check for a cached template before doing heavy processing might also be very important performance wise.
  
  --
  campertoday.nl, Module development, Dutch Zikula Community

  • 
  •  
• craigh
  
  

  • Rank: Developer
  • Registered: Jun 16, 2003
  • Last visit: May 29, 2010
  • Posts: 1967

  Posted: Apr 20, 2011 - 01:04 PM

  I am very pleased with this discussion so far. It has really helped us all think about what is supposed to happen with caching.
  
  unfortunately, I've seen too many 'I'm not sure' and 'I'll have to check' type comments to feel like we have closed the book on this issue. Obviously, somebody needs to truly understand Zikula caching and give a definitive word. Some testing may be in order here to confirm the behavior we expect.

  • 
  •  
• drak
  
  

  • Rank: Software Foundation
  • Registered: Jul 21, 2001
  • Last visit: May 31, 2010
  • Posts: 624

  Posted: Apr 20, 2011 - 06:10 PM

  It's all about how you implement caching. Ultimately you need to determine a cache id. You dont need to focus on overall uniqueness in the system because Zikula factors in template name, theme, language, module name etc. You just need to make a unique identifier for the data. For a single object, the ID, or for paginated lists, the start and range, and for random data, lists of IDs. It would all depend on the complexity of your module.
  
  Remember, caching goes deeper than trying to avoid SQL calls, actually, the controller can be the wrong place for that. The database layer is where we should be concentrating on caching (and we do). DBUtil does it automatically, Doctrine does it automatically now and Doctrine 2 has a clever UoW pattern which caches even if you haven't got backend caching.
  
  Looking at it another way, if pages are unique by their get request, that is where we should be looking at for caching, and not implementing anything in the module code, but at framework level. If caching is enabled and we get a request for /news/view/1 then that should be the caching key and it can be framework level. There would be no reason to have any controller specific cache handling in this case. It's all about how you implement the caching - there are always two ways to skin a cat.
  
  Something to look at later for sure.
  
  Drak
  
  --
  Zikula Lead Developer
  Board Member of the Zikula Foundation
  Follow me on twitter.com/zikuladrak

  • 
  •  
• craigh
  
  

  • Rank: Developer
  • Registered: Jun 16, 2003
  • Last visit: May 29, 2010
  • Posts: 1967

  Posted: Apr 21, 2011 - 01:34 PM

  OK, here's another pertinent question....
  
  what is the difference between render caching and theme caching? and why (in Theme settings) can you exclude certain modules from theme caching, but not from render caching?

  • 
  •  
• craigh
  
  

  • Rank: Developer
  • Registered: Jun 16, 2003
  • Last visit: May 29, 2010
  • Posts: 1967

  Posted: Apr 22, 2011 - 07:14 AM

  craigh

  Some testing may be in order here to confirm the behavior we expect.

  
  So, in order for me to understand it, I needed to use it and abuse it and figure it out. I've begun to do so by writing some code to demonstrate the various ways of usage. If you want to check it out (please do!) you can download my HelloWorld module for Zikula 1.3
  
  to answer a few of the questions raised earlier:
  1) cacheid is not required to be set unless one template is used to display multiple contents (like article.tpl renders a bunch of different articles or something). In these cases, you have to generate and assign some unique id. Thanasis' point about referencing the function is probably unneeded unless you are using the identical template for both functions (possible but unlikely).
  
  2) compileid is probably not worth playing with. Compiling basically prepares a PHP version of the Smarty template (open one and look at it). So it is just a 'native PHP' version of Smarty code. Since you probably don't need a bunch of different versions of this, you can allow smarty/view to handle this. At the moment, I'm not sure I can conceive of a situation where you would want multiple unique compiled templates.
  
  3) cacheid and compileid are both autogenerated and are related. for example, you will end up with two compile files something like:
  alwayscached-7e4cdcd4bcc2a5fc3f11b48766f968c3.tpl.inc
  alwayscached-7e4cdcd4bcc2a5fc3f11b48766f968c3.tpl.php
  and a cached file like:
  d41d8cd98f00b204e9800998ecf8427e-alwayscached-7e4cdcd4bcc2a5fc3f11b48766f968c3.tpl
  
  notice that the long hexidecimal compileid is also in the cacheid.
  
  I have more to learn, but I thought I would share what I have with you so far. try out my demo :)
  
  by the way - this doesn't really address the render vs. theme issue. I think I know the answer there, but was hoping someone else could shed some light...

  • 
  •  
• craigh
  
  

  • Rank: Developer
  • Registered: Jun 16, 2003
  • Last visit: May 29, 2010
  • Posts: 1967

  Posted: Apr 22, 2011 - 08:28 AM

  just implemented another demo to show the value of checking is_cached(). The summary of this is that there is (in its current implementation anyway) real value in doing a check and returning the cached template before doing any logic or DB fetching if it is available. This could dramatically speed up your module if utilized properly. Check the demo module code for example.

  • 
  •  
• craigh
  
  

  • Rank: Developer
  • Registered: Jun 16, 2003
  • Last visit: May 29, 2010
  • Posts: 1967

  Posted: Apr 23, 2011 - 02:40 AM

  just implemented additional demo features to demonstrate the varying methods of clear_cache(). There is a lot of internal 'inline' documentation to help you understand how it works. Check the demo module code for more!

  • 
  •  
•  
•  

Users on-line

• AllKnightAccess,
• clclo

This list is based on users active over the last 60 minutes.