@Oetterer - first, I'm glad you're enjoying Cargo!

What you're saying is true, although I can't think of a way to change the SF code to fix that problem. But what you can do is use "mapping template" instead of "mapping cargo table/field", and then create a template that adds the namespace and calls a query around it. The only real problem with "mapping template" is that it runs slower - which may or may not be a problem in your case.

ok, no problem. My workaround is using a category as well as an individual namespace. that works fine. I just wanted to mention this behaviour.

btw: glad you read that "exited" correctly. :)

Okay, cool. Yes, it's good to know about that problem - I wish there were an easy solution.

Yes, I figured that you did not "exit" using Cargo. :)

I dug a litte into the code and I might have a suggestion. I admit, it's preliminary, since I can't fathom all the implications. Maybe you can comment.

What I did (working on SF 3.4): In "includes/SF_Utils.php" I patched public static function getAllPagesForNamespace( $namespace_name, $substring = null )
changed l. 650 from:

	$pages[] = str_replace( '_', ' ', $row[0] );

to

	$pages[] = $namespace_name . ':' . str_replace( '_', ' ', $row[0] );

also to be backward compatible with the current application of mapping template, on "includes/SF_FormPrinter.php" I patched function formHTML( ... )
changed l. 1045f from:

		} elseif ( $sub_components[0] == 'values from namespace' ) {
			$possible_values = SFUtils::getAllPagesForNamespace( $sub_components[1] );

to

		} elseif ( $sub_components[0] == 'values from namespace' ) {
			$possible_values = SFUtils::getAllPagesForNamespace( $sub_components[1] );
			$possible_values_for_mapping_template = array();
			foreach ($possible_values as $value)
				$possible_values_for_mapping_template[] = substr($value, strlen($sub_components[1]) + 1);

and line 1106 from:

		 if ( array_key_exists( 'mapping template', $field_args ) ) {
			$possible_values = SFUtils::getLabelsFromTemplate( $possible_values, $field_args['mapping template'] );

to

		 if ( array_key_exists( 'mapping template', $field_args ) ) {
			 if ( isset($possible_values_for_mapping_template ) ) {
				$possible_values = SFUtils::getLabelsFromTemplate( $possible_values_for_mapping_template, $field_args['mapping template'] );
			} else
				$possible_values = SFUtils::getLabelsFromTemplate( $possible_values, $field_args['mapping template'] );

Now the mapping for "values from namespace" seems to work with cargo and mapping template. BUT (big BUT)
Here is what I havend tested:

• I coudn't test smw, since I don't have it installed on my dev system atm
• I can't begin to fathom, what SF_AutocompleteAPI.php and SF_Utils.php do else with function getAllPagesForNamespace. If this patch breaks those applications, an easy workaround would be to implement a special function getAllPagesForNamespace just for the "values from namespace" part.

That's what I got so far. I would like to hear your opinion sometime.

Interesting. I had not tried "values from namespace". Both "values" and "values from category" work. I confirmed that "values from namespace" is problematic for the other mapping parameters as well.

and unfortunately, my code example does more than expected. it did produce a correct mapping on values from namespace but somehow my next field with values (no from namespace or from category) also got the mapping applied. very strange behaviour. I reverted to the original code and used values from categories instead...