Add condition to check how a content is viewed.

sounds useful, but......

* drupal currently doesn't support more view modes, there is only teaser, page on/off
* even supporting only teaser and page would be a bit tricky. Probably best would be to add a new entity type to workflow-ng, called "boolean", add the existing $teaser and $page boolean to the event info and finally add a condition to check a boolean.

hm, only this from above
"Probably best would be to add a new entity type to workflow-ng, called "boolean", add the existing $teaser and $page boolean to the event info and finally add a condition to check a boolean."

You would also do it that way with a new entity: workflow_ng_invoke_event('node_'. $op, array('node' => &$node, 'page' => $page));

-> The new entity has the advantage that you can write specific actions / conditions for it.

* workflow_ng_invoke_event('node_'. $op, array('node' => &$node, 'page' => $page));
This is good, but only for the operation 'view'. (Read docs about hook_nodeapi)

* @token integration:
+ else if ($entity_type == 'boolean') {
+ $tokens['node']['page'] = t('Whether the node appears as a page. (@yes/@no)', array('@yes' => t('yes'), '@no' => t('no')));
+ $tokens['node']['teaser'] = t('Whether the node appears as a teaser. (@yes/@no)', array('@yes' => t('yes'), '@no' => t('no')));
+ }

This says, add for each boolean the tokens 'page' and 'teaser', which clearly makes no sense. You could only add one general "on/off" token for the entity boolean - but I don't know if that is very useful.
I suggest to add a condition, which allows to check a boolean in the way if ($page) do ... -> I'd add this to workflow-ng's conditions/actions. Then users can use it to check the existing boolean values.

hm, I think something went wrong with your patch. It removes the system.inc file and adds it back again - so I can't read your changes. Please re-roll it.

#8: You don't need to. This is covered by workflow-ng for you - as it will only list token help for entities that are available.

* I've add a condition for Boolean.
* In case a page is viewed I pass also the $page and $teaser.

That sounds fine :)

you need to declare them as workflow-ng arguments, then you pass it to event. so workflow-ng knows that these are arguments of the type boolean, so it applies the token of "boolean" to it and allows you to use the condition, which you have written for booleans.

You need to write the token integration, for the entity type "boolean", not for each instance of it.

Do we really need this boolean entity? I think not, because:

1. A 'boolean' may not provide for the future, where Drupal may have more rendering modes for a node (which is already the case for D6).
2. We can simply store the redering type on the node object itself. E.g. $node->_wfng_teaser = $teaser etc. As far as I can see, it's allowed to "ruin" the node at this stage. In fact, at this stage the node is already "ruined" by node_build_content() and node_prepare(). BTW, for this reason the administrator should not execute an action which saves a node which is being viewed.

hm, in d6 the parameters of hook_nodeapi op=view are the same as in d5. So a boolean fits, even in d6.

@2: indeed. However saving should be ok, as modules usually only save their own values of $node. However I'd consider "polluting" $node as bad style.

I need to test the patch, however it already looks good to me.

Here's a different method to solve this. See attached patch. (Hello, Amitai! I wasn't online so I didn't read fago's last message where he said he liked your patch ;-) Your patch isn't _bad_, and in fact I probably wouldn't have bothered writing my own solution if I knew of his opinion ;-) )

So,

I've introduced here a new entity, 'rendered_node'. This will allow us a new class of conditions and actions that work on such entities. I've supplied a sample action: "Overwrite rendition of content with typed-in HTML." This action let us implement the 'premium' module all in Workflow-ng!

But there's another nice action that can be written for such entities: "Render a previous revision." This will be useful for those asking "If somebody edits his profile node, I want all users to see the old version till I approve the changes."

(But feel free to scrap this patch.)

thanks, for this interesting ideas :)

However, I don't think that "rendered_node' is a good idea, as this won't allow using 'node' conditions, actions any more. For this we would need type inheritance ;). So let's go with the boolean way. Does amitaibu's patch work for you mooffie?

Regarding approve changes: I think for this case the revision moderation module fits better. (check http://drupal.org/node/175414 for even scheduled publishing of revisions :)

However, the idea of altering the showed content of a node at runtime is nice. It could be already possible with the current system. Write an action that alters the printed html of a node - but don't return the node so it won't be saved but take the node by reference. So the changes should apply to the node without having workflow-ng saving the node for nothing.

regarding "// At this stage $node is tainted;"
I don't think it's really tainted. Saving a node in this state should work fine, doesn't it?
Yes there are some additional properties in the node object, but no module should go and save it.

[...] let's go with the boolean way. Does amitaibu's patch work for you mooffie?

OK, you're the judge here :-)
I've just downloaded Amitai's patch and I'll give it an inspection today or tomorrow.

(The following is my reply to some other points you raised, but you don't need to reply to it as it seems we'll not be going the 'rendered_node' route.)

regarding "// At this stage $node is tainted;"
I don't think it's really tainted. Saving a node in this state should work fine, doesn't it?

I don't think so. Before hook_nodeapi('view') is called, the following operations take place:

$node->body = str_replace('<!--break-->', '', $node->body);
...
$node->body = check_markup(...);

So we don't want $node->body to be saved at this stage. We also don't want to send this node via email... because the next node_view() will process this botched $node->body.

OTOH, I wonder if anybody would really find a need to carry on this sort of actions on a node in a 'node_view' event. Seems unlikely.

Regarding approve changes: I think for this case the revision moderation module fits better. (check http://drupal.org/node/175414 for even scheduled publishing of revisions :)

Oh, that looks nice. I should give it a try soon. Yes, maybe it makes my proposed "render a previous revision" action unneeded.

I don't think that "rendered_node' is a good idea, as this won't allow using 'node' conditions, actions any more.

'node' conditions and actions are still allowed, becuase besides 'rendered_node' there's the usual 'node' argument.

'rendered_node' is in addition to 'node'. It doesn't replace it.

[...] the idea of altering the showed content of a node at runtime is nice. It could be already possible with the current system.

Yes, it's already possible with the current system, but:

The 'rendered_node' entity gives us semantics, too. If we don't have this entity, all the conditions/actions that can operate only on rendered nodes will be listed, in the drop-downs, together with actions that don't. This new entity let us have some order.

This 'rendered_node' entity wasn't intruduced just to solve some technical problem. It was introduced to allow a new class of actions and conditions: those that have meaning only for rendered content. But perhaps there are only very few such conditions/actions. Perhaps there are only one or two. So it might very well be that you're right and that this entity isn't all that needed. OTOH, this 'rendered_node' solution looked elegant to me, and Elegant Things tend to be the Right Things.

But let's move forward, I'll test the 'boolean' patch very soon.

Does amitaibu's patch work for you mooffie?

Yes, I can confirm that it works.

Currently it doesn't expose the boolean entities as tokens. But doing so in the way we're doing it with [status] and [promote] would fail in localized environments.

(The patch does not apply cleanly. I'm not uploading a clean patch because the localization issue is yet to be settled.)

hm, but the localization issue doesn't affect this, as it doesn't use tokens?

hm, but the localization issue doesn't affect this, as it doesn't use tokens?

That's true. Amitai's patch doesn't use tokens, and can be applied as-is. It works.

The two boolean entities (one for 'teaser', one for 'page') can be examined by the admin using a condition --workflow_ng_condition_token_boolean-- that Amitai provided.

That's perfectly OK.

It's just that earlier in the discussion you asked to expose these entities as tokens. Probably your intention was that the admin would examine these entities via tokens, not via a WF condition. Both ways are valid.

(You want me to expose these entities as tokens? And, if so, you want me to also remove the condition, 'workflow_ng_condition_token_boolean'?)

sry for letting this lie so long. I prefer the solution as boolean entity, so I've taken amitaibu's patch, adapted it to the current 2.x codebase and committed it :)

thanks!

You know, I feel it was a miss not to pick my solution (comment #17).

A reminder: I introduced a 'rendered_node' entity. I felt this solution is so elegant and powerful that I didn't bother to glorify it _too_ much. I think I erred here.

I'm re-opening this issue just so that my gloom thoughts appear on your radar ;-) Feel free to close it. I stumbled upon a support question that could have been solved by a 'rendered_node' entity.

that's with the current solution possible too - so there is no cause for your solution (which result in the "node" actions not to work)

-> one can write actions like
my_module_my_action_filter(&$node) {
change($node)
}

and it won't be saved by workflow-ng, as you haven't returned array('node' => $node)