Provide overview of all mappings for all bundles

I'm a good way into coding this, so marking as mine.

This patch adds an overview of all mappings.

This is a dirty patch, it includes the patch from http://drupal.org/node/1106662#comment-4268006 so that you can see the overview. You actually have to type in /mapping at the end of the URL, though, to see the page.

Some things to consider:

1. The links to the edit form for Comments does not work. Why is there an admin path set in the Comment entity if there is no admin form?... I have no idea. I also don't know why Taxonomy has no admin path set, catch says this is an oversight.
2. Whether we want to provide an interface for changing the mappings of Other Template Variables. I think we do.
3. Whether we want to allow users to add Other Template Variables. They would have to add the variable's mapping using code in preprocess, so this is less straightforward.

I'm attaching a screenshot for discussion purposes.

In looking at this, I think it might be clearer if the 'Fields' and 'Other Template Variables' were both set to that light grey and all other rows had white backgrounds.

I'm fine with sticking to the read-only at first.

I guess some of the iterative code that gets all the fields for a bundle could be used... other than that, I'm not seeing where the overlap is, but I haven't worked on that like you have so I could be missing something obvious.

Currently this page is only shown to admins with RDF mapping premissions. I think it would only make sense to use RDF if we have a non-admin version. I think it does make sense to offer that, though, and we could reuse the code from this display. I think that it would have to be displayed at a different path, though.

If it is a standard page at a standard URI on all Drupal sites with this module enabled, we might even add some VoID about the site and make it an easy access point for those who want to know more about what data is exposed. This could actually be extremely useful, particularly for those trying to access data from other sites (say, using SPARQL Views).

If we can figure this out quickly, I'd love to have it coded for this weekend's Drupal Gov Days. I'm not going, but I know there will be a few talks about Linked Data stuff. I can dedicate time to working on this.

There could also be an interface that would generate export code for entities so that they could be automatically added as SPARQL Views resources on another site.

This would mean it would be as simple as pressing that button and importing the types you want, and then you could have immediate Views access to that external Drupal site... this sounds pretty rad to me!

Rerolled with a small fix to make the mappings overview the MENU_DEFAULT_LOCAL_TASK...

Would it be better if there were a listing of all the tabs on the first page?

Thanks for checking it out, Miles :) Here is another one with just the Fields and Other Template Variables headers shaded.

After looking through the other config pages, it turns out only two others use tabs (in core, at least), and neither of those two have an overview list. While I think that it is not optimal to have the entire RDF Mapping overview on the page, I'm tempted to follow convention. In this case, convention would mean we have a default local task, and I think that RDF Mapping Overview is a better default task than RDF Namespaces.

Perhaps there is another RDF config page we need, and if there is maybe it would be better as the default. Anyone have thoughts on other config pages we may need?

Gah! Here is the patch.

Some really nice improvements in there. For those watching at home, it also:

• Uses real path instead of regex-ing the admin path like I did
• Adds edit link for the title field, which is handled with the real fields in Field UI
• Ensures RDF UI is enabled before outputing links to RDF UI pages

I like the new table structure, I think it is much clearer. However, I think that making the distinction between Fields and Other Template Variables is important. Fields can be added by the user and have RDFa output automatically. OTVs can only be added by a dev or themer and require their own RDFa handling. This confuses people like Earl Miles who couldn't figure out how the node template variables got their mappings, so I dont' think we want to conflate the two. What do you think? If you agree, then we could just put those headers back in there (and probably change the striping).

BTW, Miles, would you mind moving the namespace changes to another patch? We don't necessarily need another issue, but I'd like to keep the commits distinct (just to appease the version control angel on my shoulder).

Looking good!

Unfortunately, there is nothing that really documents the other template variables.

Basically, they are things that are added to $node by other modules using hooks. For instance, the user module adds the author's name and picture with hook_node_load. These are not actually registered as field values, so they are magic variables as far as the node object is concerned... they don't go through hook_preprocess_field, which is where the RDFa wrapper is set.

For the most part, users will be interacting with RDFa for fields. Advanced users could potentially figure out how to wrap magic variables in RDFa, but the focus of the work is on fields, which are generalizable. However, because in the particular instance of nodes the template variables are mapped and wrapped with RDFa by core, we want to display these in the table... and eventually add a UI for changing these mappings as well.

I think that splitting them into two tables would be somewhat confusing because we are using separate tables for separate bundles of an entity.

In the spirit of brainstorming, two ideas that are most likely really bad:

• First column could have a rowspan, so there would only be two cells in that column. One is Fields, the other is Other
• Make background colors slightly different between the two. IE faint blue tint to fields, faint green tint to variables

+++ b/rdfx.admin.incundefined
@@ -4,7 +4,157 @@
+  // Add a heading for the Other Tempalte Variables section of the bundle. This
+  // lists all of the mappings for template variables that are added through
+  // preprocess. In order to display RDFa for these template variables, the
+  // RDFa formatting must be added in the preprocess. For an example, see

So you are talking about this comment, correct? We need a better description of why a separate process is required for these variables.

Powered by Dreditor.

We'll be going with something more like the screenshot in #16, I believe.

I thought we decided not to explain the non-field field distinction in the UI but would leave it for documentation? That is, that there would be a link to a page on Drupal.org that explains that there are field predicates (and that RDFa for those get added automatically) and then there are these non-field predicates (and that you need to do special work to add those in the RDFa).

If you agree with that, I think that for the most part that discussion would be another issue. The only part in this patch that I think would be affected is the comment I posted and the one below... and possibly we'd want to come up with a better variable name than $fake_fields for the array of "template variables", but I think that variable name works for now.

+++ b/rdfx.admin.incundefined
@@ -4,7 +4,157 @@
+    // The bundle's RDF mapping array may contain mappings for content variables
+    // that are not fields. The bundle's field array may contain fields that are
+    // not in the RDF mapping array. In order to ensure we get all the available
+    // fields and all the mapped content variables, we compare the arrays.

Powered by Dreditor.

I've created the other issue at #1174436: Document the difference between Field API fields and fake fields

I will try to rework the comment and will post a revised version of Miles's patch.

First comment changed to:

+    // The bundle's RDF mapping array may contain mappings for entity attributes
+    // that are not fields. The bundle's field array may contain fields that are
+    // not in the RDF mapping array. In order to ensure we get all the available
+    // fields and all the mapped entity attributes, we compare the arrays.

Second comment changed to:

+  // Add any non-Field API entity attributes.

Ok, this one should apply.

Talked with scor about it over Skype, we agreed that we could commit this and move the two comments to their own issue.

So... fixed with b4cb304! Thanks miles for the UI insight.