By TheWhippinpost on
In common with lots of people I guess, I've always got an eye on minimising calls-to-database and other unnecessary processor loads so I hope I'm missing a trick here.
I'm wanting to control the visibility of a block - by content type - which houses PHP code. Surely I don't have to call-up yet another instance of a node to determine the content type of the page I'm on?
Comments
Should be cached
node_load should cache its results and be pretty cheap.
Have you turned on the devel.module SQL logging to see if this is really a problem for optimizing?
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Hi dman - Yeah, well, I have
Hi dman - Yeah, well, I have the devel mod but the SQL logging is b0rked:
It just seems overly cumbersome to have to do a node_load in order to verify you're viewing a node that's already loaded on the page... only to then have to do it again to perform the code in the actual block.
Mike
not as heavy as it looks
If you see the function itself it's clearly cached in current run scope, so fetching the current node is really no more cumbersome than doing a variable_get(). You want a cumbersome function, try menu_get_menu()!
I too used to avoid node_load() for psychological reasons, but all you are doing the second (and fifteenth) time a node object is needed is retrieving a handle on the thing that's already initialized.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Cheers dman, thanks for the
Cheers dman, thanks for the re-assurance on the cache.
I hear what you're saying; I just expected to be able to access stuff like content type from:
etc...
In other words, the kind of stuff that's available at the theming level as a lot of block-work, I would'a thought, is theming-type work.
Anyway, never mind - I'll look forward to my first encounter with menu_get_menu then ;)
Mike