[development] CCK per field CRUD settings, caching complexity

[John Handelaar]

Bèr Kessels wrote:
> Op zaterdag 27 mei 2006 21:42, schreef Adrian Rossouw:
>> i think the object should always be completely cached (ie: one cache  
>> per node)
>> but the node load access mechanism should trim what you don't have  
>> the right to see.
> 
> Sounds like a plan. But this defeats the whole point of caching..... But I 
> will certainly investigate this route. 
> 
> Another concept Ive been looking at is caching per chunk. So not caching a 
> complete node, but only caching the parts of the node and then compile them 
> on load. There could be a possibility to cache that compiled version too.

At the risk of making a number of people vomit,
I could point out that this is the sort of thing
which Smarty [1] is exceptionally good at already,
what with its ability to cache areas within pages,
and its support for per-user cache versions [2].

If you need to cache the hell out of everything,
the additional processing added by the Smarty
class would definitely be outweighed by the
cache benefits.

Plus it can live at the theme level.

Site admins would have to be very careful to
disable Drupal's own caching, though.

jh



[1] But not the current Drupal Smarty theme engine,
     I have to add.

[2] By inference.  It can switch based on arbitrary
     theme-set criteria which in our case could be
     $user->uid.



-- 
-------------------------------------------
John Handelaar

E  john at handelaar.org    T +353 21 427 9033
M  +353 85 748 3790    http://handelaar.org
-------------------------------------------
Work in progress: http://dev.vocalvoter.com
-------------------------------------------