On Fri, 2 Jan 2009 10:56:45 -0600 Larry Garfield larry@garfieldtech.com wrote:
On Fri, 2 Jan 2009 17:42:39 +0100, Ivan Sergio Borgonovo mail@webthatworks.it wrote:
Of course if what get into head (drupal_set_html_head()) was a structured object rather than a string... I wouldn't have to think to write a module so that each function can easily modify META... but that's another topic...
If there is no core global object and core global workflow and I need one... I wouldn't know how to build it in a module. That's what I'd like to learn.
thanks
I'd say you're on the right track with a hook. It's probably easier to explain with examples. I'd suggest something like:
hook_meta() {
[snip]
Make sense? (Exact implementation is left as an exercise for the implementer.)
Actually I was looking for a solution for D5 (sorry) and when you posted your suggestion I didn't have any reasonable book at hand. Now after some hours of sleep and reading the right book I find your solution very drupalish but a bit convoluted.
Supposing my META module is called mymeta...
I'll have to provide a
function mymeta_meta() {} hook that just take the place of a global object containing structured META information.
a
function mymeta_hook_info() { return array( 'mymeta' => array( 'meta' => array( 'output' => array( 'runs when' => t('Meta are going to be sent')... }
All modules that would like to change the meta should provide a anothermodule_meta_alter hook.
When I'm near to output the page (mymeta_preprocess_page) I'll run all _alter hook by calling module_invoke_all('meta','output'); (?)
Anyway this still make "context" recognition a bit hard. The _preprocess_page will have to introduce it's logic to actually know what's being displayed. Furthermore it looks a bit too much module centric.
eg. I've modules that do some stats and they are not "content" centred. For this kind of META source a "module based" approach may work... each module may actually offer an _alter hook to inject context independent keywords.
But suppose I've a page that consist of an "external" taxonomy, a list of items, an external feed of some sort and some content. Some of the events that may generate META may be context independent, some may be able to produce META efficiently just when the content is created etc... So while _preprocess_page may(?) be a good place to "close the circle" the hook system seems overly complicated to deal with the work-flow/dependency problem.
Surely _preprocess_page avoid the need of 2 modules one that define a global object and one that output head since in spite of module weight it exploit the internal work-flow of page creation.
On the other side relying on system.weight is a bit risky since we are missing a proper dependency tree in contrib and well it looks like a PITA to build one.
If you've any suggestion for D5 it'd be still welcome.
I'm trying to follow the 2 modules with different weight path (meta_prepare, meta_deliver) where the former has a function with a static wannabe array (just the way drupal_(s|g)et_html_head works but with a structured array in spite of a string)... but when meta_deliver menu get control... the static is empty (?).
Actually originally it was a whole class with methods to add meta-meta-data about priority etc... to META but to track down the problem I just cut&pasted and renamed the drupal_(s|g)et_html_head functions. But the static string is still empty when I call the get in the meta_deliver menu.
thanks