7.x-2.x FieldAPI handler

Hi,
I use the last 7.x-2.x version from today 03/06/2012 and I applied the patch from http://drupal.org/node/1458912#comment-5693992.

I have a view with the FieldAPI handler option, an integer type Field to base the rows order on, named "Order". In my database the "Order" field value for these rows goes from "1" to "135".

So first I click on the header to order the rows by "Order" ascendant. The view is ordering as expected. I click "Show row height". The Weight value is "-135" for every row.
Then I move some rows in the table. Now the Weight value goes from "-135" to "-1". Ok.

When I save the view, the update in the "Order" Field table in the database is working as expected, as the value for the rows I moved is correctly updated. There is only one problem : the values are now going from "0" to "134" (they should go from "1" to "135").

Thanks for this great module!

Hello,
I think it's a problem because the module should not alter the way the Field values you use in the view as handler were previously numbered in the database.
If the values in the view table are going from "1" to "10", and you are reordering them, the first row should keep this "1" value and the last one the "10" value.

So, more concretely, the problem is that these integers are shown to the anonymous users in nodes. This people doesn't expect that the first node be "tagged" as "0". They expected "1" instead.

Using some Field values to order the table, I expected that the module would use these values to reorder the table + update the values in the database with the same ones.

Thanks for the tip about tabledrag.js. I will have a look into it.

(yes, the "0" value appears in the database table while the "-134" one appears in the selectbox table row.)

Updated to current dev version, I see FieldAPI but have the problem: I have integer field "Weight" and more than 50 nodes, and have problem with view using pager "10 items".
If I show all items in view (without pager), all looks good.
If I set pager to "10 items", and show weight field, I see that this field have selectlist with -10 to 10 values, but some first values are equal, so first six items have same -10 values, second several have same -9, etc. Is it normal or I do something wrong?

I already have different views for viewing and ordering, so i can't use ordering via Views native api.

At 50+ items list without pager will work normally, but I plan to have 1000+ nodes for ordering, and saving so much nodes in one step will be not so good for performance. Is updating order do full node_save or only update one database table?

As I try earlier, on DraggableViews 1.x ordering with pager works normally, any chance that this will work good too on 2.x?

I think we can get count of rows in current page, and build order field data between them, and on save - get min and max values from each item, and build new ordered values. This must solve problem with ordering and pagers.

Here is quick example how to update field without do full node_save:

  $entity = node_load(33);
  
  echo "on load: {$entity->field_test1[LANGUAGE_NONE][0]['value']}<br/>";
  $entity->field_test1[LANGUAGE_NONE][0]['value']='test'.rand(10,100);
  echo "before save: {$entity->field_test1[LANGUAGE_NONE][0]['value']}<br/>";
  
  $entity2=new stdClass;
  $entity2->nid=$entity->nid;
  $entity2->vid=$entity->vid;
  $entity2->type=$entity->type;
  $entity2->field_annonce=$entity->field_annonce;
  
  field_attach_update('node',$entity2);

  $entity = node_load(33);
  echo "after save: {$entity->field_test1[LANGUAGE_NONE][0]['value']}<br/>";

I'll try to implement new handler for DraggableViews that do saves via this method.

Hey @Murz! thanks your code example.
Did you make the handler or a module to do that? because this is really an issue for me, doesn't make sense a full save to only update ONE field.

The thing is, modules such as search_api use hooks like hook_entity_update() that only are fired when a full save is done, so, if we change to an updating field only process, it will impact in everything else that is integrated with. In this case with search_api we will loose the immediately update in your search.

Maybe we can do some manual invokes of that kind of hooks?

thanks!

I've implemented the following code in fieldapi handler to update quickly field collection items. It was faster then in general.

      if ($entity_type == "field_collection_item")  {
      	$entity_wrapper = entity_metadata_wrapper($entity_type, $item['id']);
        $entity_wrapper->{$field_name} = $item['weight'];
      	$entity_new = $entity_wrapper->value();
        field_attach_presave($entity_type, $entity_new);
        field_attach_update($entity_type, $entity_new);
        entity_get_controller($entity_type)->resetCache(array($item['id']));
      } 

Can anybody see it in case of Node entities? Use it with caution - not to erase node contents.