Build views integration for field.module

Are there some tutorials of porting CCK usage to Fields API?

Well I want to add to Views ability to show custom fields in D7 but I don't know from where to start

This is a very first shot at that.

This patches exposes data for fields using the field_sql_storage engine, and link them to the base tables of all the entities using the fields. It should be enough to build simple views.

What's missing:

* Implement the custom handlers (content_multiple_handler, especially)
* Implement "link to the entity" in a generic way (not sure we have everything we need to do that right now)
* Figure out how to get a label for the field (labels are attached to the instance, not to the field, so there is no way to use that to display a prettiest and more usable description for the field)

Note: you might need to apply #645990: Fix handling of 'extra' conditions and left/inner joins first.

Way cool.

FYI: when it comes to displaying the field values, you'll probably bump into field_format() and #612894: field_format() is just a pile of code that doesn't work

* Implement "link to the entity" in a generic way (not sure we have everything we need to do that right now)

See #525622: 'as link' formatters need a generic way to build the url of an 'entity'

* Figure out how to get a label for the field (labels are attached to the instance, not to the field, so there is no way to use that to display a prettiest and more usable description for the field)

Yup. No real workaround for this, other than taking the label from a random instance of the field. People like the 'Label as instance-level property' feature...

Damien, Can you provide a simple view using your api for testing?

* subscribing

I'm currently running using this patch, and it seems ok so far. Will report any errors if or when.

Successfully added a field to a view, and also filtered by that field.

Subscribing

Thanks folks... I actually had Views up and running on a D7 Sandbox site I've just built that allows people to play with D7 (http://d7sandbox.net), but my use-case really required access to by views to fields I had added... so not currently using it at the moment. But once you all get a patch in, I'll test it hard on a live site.

Shai

+++ modules/field.views.inc
@@ -0,0 +1,246 @@
+        'left_field' => $entity_info['object keys']['id'],

Hm. $entity_info['object keys']['id'] is the name of the 'id' property in a loaded $object. In most cases, it will happen to be the same as the actual column name in the base table, but it's not a rule.

Not sure that information is available somewhere. Perhaps in the exposed data about the base table ?

+++ modules/field/views_handler_field_field_multiple.inc
@@ -0,0 +1,24 @@
+      $this->definition['field_defintion']['id'],

Typo - field_defintion

+++ modules/field/views_handler_field_field_multiple.inc
@@ -0,0 +1,24 @@
+    $this->items = field_sql_storage_field_storage_load($this->view->base_table, $object_ids, $this->definition['table_type'], $fields, $options);

Similarly, $this->view->base_table happens to match the name of the entity type in good cases, but that's not a rule.

Powered by Dreditor.

Additionally:

+++ modules/field.views.inc
@@ -0,0 +1,246 @@
+        'extra' => array(array('field' => 'etid', 'value' => _field_sql_storage_etid($entity), 'numeric' => TRUE)),

Also needs to join on 'deleted' = 0.
Field API has a delayed deletion mechanism to avoid timeouts on large deletes (i.e 'node type delete' = potentially 10s of 'field instance delete'). Views should overlook any Field data with 'deleted = 1'.

Powered by Dreditor.

Just an FYI -- this patch is the blocker on getting an alpha release out. I think we can go with any number of horribly broken features, but Views has minimal value without field.module integration.

Any effort people want to spend on Views for D7 should be spent here, first and foremost, at this point, especially since we know that we can get reviews from yched.

Is anyone actively taking this patch forward?

great job ! Work fine on my drupal 7 alpha1 platform.

sub

Here are some progress in that path. We now have configurable formatters. Sadly, core display function is still broken (see #612894: field_format() is just a pile of code that doesn't work).

This one actually works! It seems that field_view_field() actually does what we want here, we just need to forcefully set 'label' => 'hidden'.

Two (related) bugs:

• #722172: Write tests for the field integration
• #722180: Field integration doesn't support displaying fields across entity types

Per #16, I don't think the code is yet trying to filter out deleted values.

Also, we have lost the ability to select specific items for multiple value fields and group them together into a single item -- the kinds of things that were handled in content_handler_field_multiple in D6. Not sure of the best way to approach that one. We would need to add some options to the form and then use field_view_value() on the individual items instead of field_view_field() on the field as a whole to display the result. Plus we used to jump in during pre_render to retrieve the grouped values and combine them into a single item. I'm not sure how much of that would work in D7 and how much needs to be re-factored.

Just getting these items noted, in case anyone wants to tackle them.

The component changed :(

I think dereine wrote a special handler for the "list field".

Marking Fixed based on dereine's comment - If it needs to be changed back, then it can be!

Can someone start new issues for the things mentioned in #16 and #27? Those are not addressed yet. I will start them if I get a chance, just trying to let people know there is more work to be done.

I'm not trying to be theoretical here, but doesn't if ($field['storage']['type'] != 'field_sql_storage') continue; limit views to sql stored data?