What is the "attribute name" ?

Hi Dave,

This plugin integrates with the Context API, not the UI. You have to set the Context using context_set($namespace, $attribute, $value). So for example, in your case, you can leave your existing setup as it is (so that the block does continue to appear), but you'll want to add a hook_nodeapi to your site's helper module (if you have one) in which you have something like the following:

function mymodule_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  if($node->type == 'department') {
    context_set('mysite', 'current_department_nid', $node->nid);
  }
}

Then, you would set the Active Context plugin's "namespace" field to "mysite" and the "attribute" field to "current_department_nid" (feel free to rename these to whatever best suits your site).

Now, it's likely that I can very quickly whip up a Context UI plugin that automatically adds context_set data to the current context. In fact, it seems pretty necessary to certain use cases. I'll see what I come up with and hit you back in a bit with that.

I've done some thinking about this and to fill out a Context UI plugin in a way that would make any sense would require constructing an edifice nearly as unwieldy as the Panels 3 context system. Let's stick to using context_set programmatically wherever it's needed.

Thanks so much for your assistance and encouragement, Dave! I've committed the README with very minor modifications. It should be in the dev branch as well as 1.1 now.

In the context module: Namespace is context_namespace, Attribute is context_attribute, Value is context_value.

Create a file helper.module

<?php
// $Id: helper.module $

/**
* Set the context argument for context module using views_arg_context module
* See http://drupal.org/node/723792
**/

function helper_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
if($node->type == 'content_type') {
context_set('context_namespace', 'context_value', $node->nid);
}
}

Click +(plus) argument. Click Node: Nid. Click Add. Click Provide default argument. Click Radio Button Active Context. Write in Namespace: context_namespace. Write in Attribute context_value. Update.

The Attribute in the view is NOT the Attribute in the Context. The Attribute in the view is the Value in the context.

Hey adamsohn,

What would you like me to do with that information? Do you want to include it in the (admittedly minimal) documentation in the module description? If so, I wonder if someone would mind throwing together something a little more structured -- and maybe integrate it with http://drupal.org/node/774966

bryn, I'll be glad to help out here.

Just starting to get back up to speed post Drupalcon.

I'll review your recent patch, the various issues and figure out some next steps/new patches/docs

Seth, thanks for telling me about this module after Michelle's talk on views arguments. I was the Marc Antony's horses guy, but I digress...

Briefly I am trying to filter a node reference select list that appears on add & edit pages. I use the cool Node Reference URL Widget for my work flow, so the referring node id is passed to the url of the node/add page. I have 4 content types: Suppliers, Textiles, Purchase Orders and Purchase Order Details.

From a suppliers page a user can add fabrics or purchase orders using Node Reference URL Widget. Once a user adds a purchase order (ship by date, notes etc.) they can add the "details", which in this case are fabrics (fabric, quantity, price) also using the Node Reference URL Widget. So now the user is on the node add Purchase Order Details page. There is a node reference select box of "fabrics" for the user to choose. I am trying to filter the list using views so that it only shows fabrics by the Purchase Order's supplier.

Merlin felt I should be able to do this with views #767184: How to build this sql into a view, but I've had no luck.

From this thread I see (thanks Dave!) that I need to create a helper module that can hook into my purchase order detail node/add and grab the argument in the url and then do a context_set. Right now that nid is the Purchase Order ID not the Supplier ID that I need to filter the select list. Of course, I can easily pass the Supplier ID to this page using Custom Links, but maybe I don't have to.

Sorry for the long post. The attachment should help clarify this. Thanks to all involved with this. If I can get this working it will be huge for the app I'm building.

dogboy72, let's open a new issue on this, ok?

Going back to the original question and comment #1, I'm confused about the difference between contexts set using the Context UI and contexts set by modules using the Context API. Doesn't the Context UI use the Context API? It seems strange that it wouldn't. I'd hate to constantly be setting the same contexts twice, once in my module for use as Views arguments and once in the Context UI for everything else.

No, it doesn't work like that. Having now used views_arg_context extensively on a complex site, I likely will never work without it again. It's an amazingly simple tool.

1) Set up your context using the UI. For instance create a context named "testing", and trigger on a path of "/whatever". This will create a context using a namespace of 'context' (the stock context module).
Add as reactions, a number of blocks you want to appear in that context, including some views blocks, let's say for the sample views.

2) Add code, like the views_arg_context sample code (which we really need to move to it's own example simple module), which use nodeapi (for example), to set a _new_ namespace called 'node' with node info stored into it.
Now views which go looking for arguments into that namespace will be populated (or not) by node info.

Now, you have 2 different levels of context happening... but they don't conflict, they are entirely different levels of namespace. 'context' is Context UI triggered, 'node' is your custom level to pass info around.

They work together:

Context UI says "display views block X"
Views block attempts to generate content, reads 'node' context for some info as an argument.
If the argument ends up making views say "No, this view is empty" (empty value passed, for example), then despite the block being told to _appear_, it's empty so it won't anyway.

Now, if you want to get confusing, and this is more advanced, add in the following:

1) Use the same context namespace: so you can now set the context named 'context' in your module if you wish. The API for 3.0 has changed a bit, so to trigger reactions, you do need read up on the current way to invoke them correct.

2) Views can _generate_ context via args with the right addon code. I'll be submitted a patch shortly to add/demo this feature. It really needs some good UI though, and I can't see how to add it to views UI yet. But what that means that views can not only _read_ contexts, and react to them as arguments, but can also _set_ contexts based on other given arguments (say from the url), and thus pass them onto other parts of the website, which won't have to _read_ them from the url, or even know where they came from originally.

Effectively, context becomes a method to pass info along within all of Drupal, a sorely needed thing. Your theme can react to contexts set via modules, so you can flag things to be themed out differently all the way back in the module layer, but still pass thru the exact same data to the theme otherwise. Again, some demo code is coming.

This is a quicky writeup as I'm about to drive over to Design4Drupal in Boston, but it's on my list to contrib back shortly, now that I've got it working well in a complex situation.

Kudos to Bryn for creating this module, it's really become a game changer for me.

setting status back to "needs work", to remind me to contrib code examples back.

I'm building with Context 3. Where do I find the information to set this correctly?

@adamsohn: per #793594: setting a context from code in v3

In 2, make a context active in code: context_set('namespace', 'attribute', 'value').
This would then trigger all the reactions for that context.
in 3, calling context_set() is just setting a variable, not loading the context with all its reactions

yhahn on May 25, 2010: "Yep, slight API change:"

context_set('context', 'name_of_context', context_load('name_of_context'));

(note that he uses different terms for the namespace (context), and attribute (name of context))

So you use context_load now, which I'm fine with... context_set is just for setting now, which is logical.

Hey seth, just checking in here... I've been semi-AWOL since July and wondered if you had any of this demo code laying around. I'd love to include it in the new Views 3 branch I was planning on creating, and then backport to the current 1.x branch.

I just realized I demonstrated the function I published here before. Never mind this post.