Activity publisher as theme hooks

Ok went ahead and gave this a shot. It was fun :-D, bit of a dive into theme(). You can create templates like this

activity_message__HOOK__OP__type1_type2_typeN
activity_message__HOOK_OP
activity_message__HOOK
activity_message

These activity template files will have to be used INSTEAD of the token system - so either/or.

Its not so either/or. In this patch you can choose not to use the $message variable.

We probably should add this as well but I want this patch out there for debate.
http://skitch.com/supermanscott/nr1ah/activity-theme

So this allows you to do

function hook_theme() {
  $hooks = array();
  // Do all your hooks
  $hooks['activity_message__nodeapi__insert__story_page'] = array(
      'arguments' => array('message' => '', 'objects' => NULL, 'op' => NULL, 'hook' => NULL),
      'template' => 'activity-message--basic',
  );
  return $hooks;
}

And that will use the activity-message--basic.tpl.php for all inserts of story or pages, given that you have the activity template setup for nodeapi insert only for those two types.

Also I see I had a note about this needing to replace the token system we have in place, but it seems like you were able to keep it. Can you elaborate on that a little please?

There was no rational other then, "Hey this doesn't have to be either or, a theme implementer can choose to use it or not. O and I don't have to remove that textareas from the interface!". But I think it makes sense too, as you could want to theme up messages differently depending on node types for instance. Seemed to create flexibility...

Also, what is the reason for the double underscores? I know views tpls do this, but i was never sure on the reasoning behind it? Just uniqueness?

Right and to leverage developers existing experience for creating tpls. I don't think we need to describe the pattern here as it doesn't do us any good, i think. I have to try it without the 'pattern'.

This patch isn't complete really, its missing several things, like determining if that 'pattern' is needed. But wanted to get it out so we could dissect.

For improvement: http://drupal.org/node/223440 ? Maybe? I think that limits us to only tpl.php the current patch allows you to use theme functions as well. But nonetheless, important link

Hmmm. #5 poses a good question. I heavily use theme suggestions for my sites but have yet to try the patch in #2 and see how Scott's system.

I think the technique in 5 is unwarranted.

It is not what Views does.

It is not what Flag does.

That technique in 5, would force the theming to be done in a tpl file. Whereas, the patch allows it to be a function or a tpl file. And it is similar to the technique of Flag and Views.

I believe 5 is a non-starter.

Changing title to reflect my previous comment

Cool. Well I look forward to testing this patch and reporting back soon. Thanks for all your hard work Scott.

Subscribing, this would be a very useful addition. We have a situation where we want to display Fivestar ratings as themed stars (we've written a VotingAPI implementation for activity already). However, we don't want to include the Fivestar themed stars in the stored message, since any changes to the theme layer would not be reflected in the stored message.

So our stored message would be something like "Admin gave Example a rating of 80" (where 80 == 4 of 5 stars). But then we could use the theme layer to replace "a rating of 80" with the themed stars provide by Fivestar through theme('fivestar_static', $rating).

I should also note that I'm not entirely sure that a .tpl.php file is necessary for this implementation. You can do the exact same thing for theme functions actually, so instead of tpl.php files, you would have a series of suggested theme functions which would follow this pattern:

function [mytheme]_activity_message__hook__op__types()
function [mytheme]_activity_message__hook__op()
function [mytheme]_activity_message__hook()
function [mytheme]_activity_message()

An entire .tpl.php file just for <?php print $message ?> seems excessive. Especially when considering that .tpl.php files are several times slower to render than theme functions (due to the preprocess functions). However that could be an advantage since it'd allow other modules to modify the $message variable too.

Ah, I was getting all confused, I thought this was for theming messages on output not on record. I suppose we already have something for output, since it all runs through Views right? My use-case is solved through that.

All-in-all is theming stuff on input a good idea then? It seems like you'd want to avoid inserting a lot of HTML into the database that could never be changed (for example, I definitely wouldn't want to shove themed Fivestar widgets into the database). Though not storing messages would mean a completely different paradigm, where the objects (or object IDs) were stored in the database and then rendered into HTML on output. So maybe I'm just getting in over my head here. ;-)

* quicksketch steps out as if he'd never said anything

well i think sirkitree and myself had our doubts about this DX and I think this just confirms our doubts.

the goal was to provide powerful messages without having to do expensive left joins through node table and through cck table to get fields. We can do this with a relationship to CCK tables which is probably better overall.

Not sure it makes sense though to do it this way anymore. It was cool that it worked but thinking that this is a wont fix

I agree with quicksketch in #11 ;)