Possibilty to pass arguments to view

Created a patch with 3 arguments.
I does its job, but it is not super beautifull.

I have tested it quite thoroughly but would like to know about improvement.

I agree with you that those fixed arguments are not neat at all.

What I would prefer though (I have been playing around with it but couldn't do it yet) is really use ctools contexts.

This would be trivial if we would know what type of arguments our View needs.
Say the View needs an user-id and a node-id, we could then add:

  'required context' => array(
    new ctools_context_optional(t('Argument 1, User ID'), 'user'),
    new ctools_context_optional(t('Argument 2, Node ID'), 'node'),
  ),

to the plugin definition and in the settings form nice selects-boxes show up with the real available contexts.

My problem to accomplish that, is that we have to alter the plugin settings after the view has been selected.

2 possible methods:
1. Select a View, extract the View's arguments, add those arguments to the plugin definition.
2. Load the configuration form, load 'all available contexts', add those contexts to the plugin definition as optional. If there are 2 available contexts, you can select 2 arguments. If there are 4 available contexts, you can select 4 arguments.

How do you think about that?

Like this one from ctools/plugins/access/context_exists.inc

  'required context' => new ctools_context_required(t('Context'), 'any', TRUE),

And this variant with multiple optional contexts.

  'required context' => array(
    new ctools_context_optional(t('Context'), 'any', TRUE),
    new ctools_context_optional(t('Context'), 'any', TRUE),
  ),

Hi Phil,

Think we got a nice patch now!

What is changed since first patch:
- Arbitrary number of arguments.
--- Function 'views_get_view_result' is called with 'call_user_func_array' to make that possible.
- Select dropdowns for arguments selection instead of text fields.
--- Apparently available contexts are known in the settings form.
--- Its impossible now to pass arguments without a context (hardcoded argument). I think this is not a bad thing.
- Code cleanup
--- Moved views options list to '_ctools_view_access_get_views_options_list'.
--- Added arguments to plugin summary.
--- Code commenting, etc.

Hi Phil, what shall we do?

Thanks for your review/feedback!

So the goal of this issue is the ability to pass arguments to a view.
Patch #2 had a fixed amount of arguments and an option for using a context or direct input. Context are recognized by a specific pattern (%node).
Patch #4, #5 has a flexible amount of arguments and both direct input and context. Context are recognized by a specific pattern (%node).
Patch #8 dropped the direct input and favors choosing a context with a select box.

My thought about dropping direct input is that it is more error-prone and user-friendly, because you don't have to remember/lookup available contexts but its just click and go. Feels more ctools/panels-alike.
I am not completely sure, but can't you add a context of type "String" and use its keyword as a substitute for direct input? I will check that within a couple of days.

As of 'visiblity rules'. That's not working, but it should, so could call that a bug.

I'll put some time on it this week and then I come back here about it.

Hereby the new patch.

@heivoll: the visibility rule setting is fixed with this patch now, but I think the reason it didn't work is a bug somewhere in panels. In the access-plugin definition "all contexts => TRUE" is used, but those contexts are not passed to the settings form. Those contexts are sideloaded now and therefore available.

The string-context is available but not configurable in ctools latest stable release (7.x-1.4). So therefore you need ctools 7.x-1.x-dev today.

I also killed watchdog notices/warnings by better checking for empty arrays/values.

@tripper, heivoll: would be great if you could give this patch another try!

Hmm, I missed something obvious.

1. String context
The 'string' context is different that the other real objects like user, node, etc.

In the function _ctools_view_access_get_argument_from_contexts() that is checked now. Silly I did not test that properly.
This is totally separated from the input method via a panel-visibility- or selection-rule. It would happen to with direct input (i.e. %string). So I am a bit worried that there could be other unknown exceptions too.

2. Argument selectors
About the input method with the multiple selectors.
The thing what happens is that all available contexts will be presented here independent if the View can handle them. The reason is that we don't have a proper ajax-callback that loads the view when you selected it. But it sounds like a better, less confusing UI.

So at least you will see one context (that is "Logged in user") and if your are on the node-panel you will see 2 ("Node being viewed" & "Logged in user") that you can pass into the view. If you add a string-context, you'll see 3 argument selectors.

In addition to the patch file also added 'test_node_panel" that makes use of the "test_view".

So test setup:
panels 3.4 stable
ctools 7.x-1.x-dev
patched ctools_view_access
test_view.txt
test_node_panel.txt

Maybe this is getting a bit to difficult all the way, but I still hope we could manage to fix this feature.

Yes, clear. That means work to do. I'll dive into it: both ajax and multistep.
Nice change to learn something new!

Tried a long shot on the ajax, but at gave up. Got to many issues with ctools+ajax.

So what I did was using patch #5 and then I added functionality from the later patches:

• Use 'call_user_func_array' to pass Views arguments
• Changed the description of 'Arguments': available contexts (their keywords) are visible now. So no dropdowns, but still some feedback to the user about what can be put in
• Stub-context for string (although you can also fill in absolute values)

I tested:
Both 'selection rules' as 'visibility rules'.
Log notices

If we want to give feedback to the user what arguments a view can handle, we might do that by extending the view-instance label with arguments. The view object contains this information. But this functionality is not in this patch though.

Thanks!