Views Arguments implementation.

Glad to see someone is working on this, I was just going to make a feature request. I see you've given modules a way to add their own handler, which was another concern -- the date field in particular is going to need special handling. I'll give this a try later today.

Thanks a lot for this patch dopry. I was in fact needing that just this morning :-)

One remark though :
Do you really have to append the fields labels in the $arguments table keys :

$arguments['field_'.$field['field_name'].'_'.$field['widget']['label']] = $argument;

- It makes the patch practically useless with views.module current limitation to 25 chars for arguments names
(I think I saw you posted an issue for views about that earlier today)
- The labels are plain text, they have spaces, commas, accents (I'm french), i'm not sure these "special" chars don't mess with the magic...

Plus :
(same code line) isn't there a extraneous "field_" at the beginning of the key ?
$field['field_name'] already starts with "field_".

I don't think multiple instances of the same field *should* be separate, as far as Views is concerned. That's pretty much the whole point of having them be the same field. If they are semantically distinct, they should be different fields.

JonBob: you're talking about different instances of a field in different content types - they should definitely be semantically equivalent, and thus treated the same way.

I think dopry was wondering about multiple-value fields (different "instances" in the same content type, although "instances" is probably an improper term in this case).
I'm not using multiple fields right now, so I'm not sure how this is to be managed.

(I guess I'm doing my - somewhat arrogant ? - mediator/interpretor number)

Anyway, i'm currently using dopry's patch with the incriminated line changed to

$arguments[$field['field_name']] = $argument;

and it works quite fine (once again, no multiple fields involved on my side, though...)

"What happens if you create two node_reference fields on one content type? [...] I was worried that value $field['field_name'] could be duplicated in a single content type, on different fields."

Nope, this can't happen. If there are two node reference fields on one content type, they will have different field names. You should be perfectly safe using just the field name.

If you end up having to distinguish items in a multiple-value field, then the "delta" attribute is what you want.

I think things work better when the following line in your patch (in function content_views_argument_handler) :

$query->add_where( $table .'.'. $column['column'] .' = '. $arg);

is replaced by

$query->add_where( $table .'.'. $column['column'] ." = '%s'", $arg);

But maybe this should be refined depending on the value type (%d or %f for number fields)
There's something similar in function content_field($op = 'insert')

Too late for me to propose a patch today, plus I don't want to steal dopry's credits :-)

A modified version has been committed. I added full summary view support, and changed the criterion for not using the default argument handling to a parameter in the database info hook. I think this is more robust, because we need to handle having more than one field defined in the same module, and they may have different argument requirements.

Ysched's comments are also incorporated.