Remove the node (load) dependency

Also, the fields are already added, I was thinking of something like this:

function fullcalendar_raw_values($vars) {
  $fields = array();
  foreach ($vars['view']->field as $id => $field) {
    $items = array();
    // The field is actually a field
    if (isset($field->items)) {
      echo 'FIELD NAME: ' . $field->definition['field_name'];
      foreach ($field->get_items($vars['row']) as $values) {
        $items[] = $values['raw'];
      }
    }
    // The field is a special node value like path or nid
    else {
      $items[] = array('value' => $field->render($vars['row']));
    }
    $fields[$id] = $items;
  }
  return $fields;
}

That would save calls to field_get_items() later on.

That creates an array, keyed by field id (entity_id, entity_id_1 etc).
That echo statement is just to prove the point that we can get the field_name if we need it.

Here's the array for a row with a date and datetime field, the title, the path, and the nid:

$field->get_items() is a Views function, not Field API. It also takes into account all of the Views options for a field, like trimming, rewriting, and tokens.

Views is already loading this information for us, if we can use it we should.

+++ fullcalendar.module
@@ -238,41 +237,39 @@
+  $entity = $vars['view']->result['0']->_field_data['nid']['entity'];

Should be $entity = $vars['row']->_field_data[$vars['field_alias']]['entity'];

+++ fullcalendar.module
@@ -238,41 +237,39 @@
+  $entity_type = $vars['view']->result['0']->_field_data['nid']['entity_type'];

Should be $entity_type = $vars['row']->_field_data[$vars['field_alias']]['entity_type'];

+++ fullcalendar.module
@@ -238,41 +237,39 @@
+  $entity->title = $entity->title;

Unnecessary. Right?

Powered by Dreditor.

The changes I proposed were twofold: one using $vars['row'] instead of $vars['view']->result[0], but also using $vars['field_alias'] instead of 'nid'.

Subscribe - using data that's already available is always a good thing :)

Since we've switched from $node to $entity, it makes sense to abstract 'nid' to field_alias. I have no idea if it matters now, or will matter later.

Looks good. No need to backport this to D6 either.

http://drupal.org/cvs?commit=491976

Hi,I'm on the last cvs version it seems that it's still related to node.
I tried to setup a user view.Users have a date field, and i added the user->name and user->date fields in the views, setup the fullcalendar. I added a page view to test it too.
The page view works perfectly, all the fields are displayed, but when i test the fullcalendar version, i get several errors and the calendar is empty.

Notice: Undefined property: stdClass::$uid in views_handler_field_user->render() (line 46 of E:\Documents\Graphisme\Perso\Projects\Drupal Dev\sites\all\modules\views\modules\user\views_handler_field_user.inc).

--> This error is repeated as many as there are elements to be shown.

And above :

Debug:

'Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column \'node.nid\' in \'field list\''

in views_plugin_query_default->execute() (line 1314 of E:\Documents\Graphisme\Perso\Projects\Drupal Dev\sites\all\modules\views\plugins\views_plugin_query_default.inc).

--> This error is just shown once.

I noticed that in the .module file, there still are a lot of code related to node (especially for the update process so i didn't digged more).
I think the problem resides in views_plugin_node_fullcalendar.inc. $base_table and $base_field are setup to "node" and "nid".
I don't know if this file has to be changed or if a views_plugin_user_fullcalendar.inc has to be created but what i'm sure of is that i can't show date fields from others type than nodes.

Thanks for the quick answer, but the patch fails to apply (HUNK #3 failed at 272) with the patch command, and git-apply "Fatal:git diff header lacks filename information when removing 1 leading pathname component (line 5)"
I'll try and see what's wrong.

Edit : seems to be the $entity->title = ''; at line 275 that wasn't added.

No problem, i understand :)
I think this is pretty good starter and it unblocked me.
I saw some remaining problems, tried to find a solution :

Line 274, added some code because :
- Views seems to keep the uppercase for the first letter of the word. So when the module tries to find $entity->Name or $entity->Uid, it doesn't work...
- Even with the full lowercase property name, the function field_get_items() returns a single letter and not array. (didn't find any correlation with something). I don't know if it's only me or it's generic, but i added few lines to set directly the property from $entity if field_get_items didn't return an array.

 // Fetch custom title if needed.
  $entity->title = '';
  if (!empty($vars['options']['custom']['fc_title'])) {
    $target_field = strtolower($fields[$vars['options']['custom']['fc_title_field']]);
    $title_field = field_get_items($entity_type, $entity, $target_field);
    if (!empty($title_field[0]['value'])) {
      $entity->title = $title_field[0]['value'];
    }else if(isset($entity->{$target_field})){
      $entity->title = $entity->{$target_field};
    };
  }

Hope this helps !

Thanks for these fast updates !
I noticed some collateral damages to these changes :
- multiple values of a same field a of node are buggy when dragging/resizing (they are moving together). This is due to the "id" property that is used by the fullcalendar to handle calEvents interaction, and corresponds to the entity id when setup in the preprocess function.

- events of other types than node are not updatable.

Hopefully, this patch fixes it for almost all situations. I also added a message class handler when getting the result message from the update function. It adds to the #fullcalendar-status div a class whose name ("success" or "error") depends on a variable passed in the json. Allows easier styling for feedback messages.

PS : this is a patch made using cvs, i don't know how to do it with git. If someone can explain me i will be able to post a git version of the patch.

#28 is right, you can't use 'id'. But #27 with 'eid' instead works fine, no need to make all of the changes in #28.

Also, we don't have a dependency on Entity API, so we can't use entity_save().
How about this:

$function = $entity_type . '_save';
$function($entity);

I didn't see the eid in #27's patch...

In .module : 
-    'nid' => $entity->nid,
+    'id' => $entity->id,

And .views.js
-            nid: $(this).attr('nid'),
+            id: $(this).attr('id'),

Anyway i'm sorry, i didn't really think about the dependencies.
what a pity to not be able to use the entity_save...

Correct me if i'm wrong, but i think the different *_save functions are not built with the same structure.
For instance node_save requires only one parameters (the $node to save) whereas user_save requires the 2 or more params (the $user object and the $edit object, with an additional $category param).
And when i tried node_save($entity) it threw me a database error (duplicate entry). So i had to node_load, then insert $date into $node and node_save($node)

Before using entity_save() i had setup a switch($entity_type), and had to take care of each type cases. I don't think this is good to take this way because :
- It would be rewriting part of the code of entity API (and nobody wants that :)
- We would have to handle all the entity_type possibles (for example, i'm going to use the fullCalendar with profile2, so i would have to handle this entity_type too, and profile2 has a dependency on entity API).

I'm sure you have many good reasons to not be dependant of entity API, so what about a double case :

if (module_exists("entity")){
  entity_save($entity);
}else{
  switch($entity_type){
    case 'node' :
      //node-specific code
      ...
    break;

    case 'user':
      ...
    break;

    default:
      drupal_json_output(array('msg' => "Type $entity_type not handled. " .  [<a href="javascript:void(0);" class="fullcalendar-status-close">close</a>]', 'type' => 'error'));
      exit();
    break;
  }
}

Since all we're changing is one field, we have no need to use all of node_save, user_save, or even entity_save.
Introducing.... field_attach_update()!

Nice !
didn't know that function...
There is one pretty small bug in the eventResize function in the .js, there is no allDay param passed like in the eventDrop function, this shouldn't be passed in the ajax call.

No chance of a backport on this one. But wow, this rocks!

http://drupal.org/cvs?commit=493720

After i updated the cvs to get this commit, nothing worked anymore... views doesn't seem to have the fullcalendar style anymore, and my current fullcalendar views says that the view style relies on a plugin name "fullcalendar" that doesn't exists.

I put this on the homepage, we need major documentation work done.

CAUTION

In 7.x-2.x-dev the custom FullCalendar display has been deprecated. Before updating your code, remove the FullCalendar display and replace it with a Page display.

Sorry, didn't see that on the homepage...
I'll try to be more useful : The '&allDay = '+ allDay in the eventResize function in fullcalendar.views.js (line 88) shouldn't be here, it throws a javascript error and doesn't launch the ajax call.

Just have to remove it

 eventResize: function(event, dayDelta, minuteDelta, revertFunc) {
      $.post(Drupal.settings.basePath + 'fullcalendar/ajax/update/drop/'+ event.eid,
        'field=' + event.field + '&entity_type=' + event.entity_type + '&index=' + event.index + '&day_delta=' + dayDelta + '&minute_delta=' + minuteDelta,
        fullcalendarUpdate);
      return false;
    }

Don't know if i should start another issue, but it seems that relationship don't work well with fc custom fields : i have a profile view with profile -> user relationship.
In a standard page view i'm able to see the both the username and the date field in the same row.
When i set username in custom title, it doesn't assign it to the entity (i replaced $entity->title = '' by $entity->title ='no title' in line 278 of .module to debug).

I'll try to find how to fix this.

Thanks for all and like you said, wow.

Ah that was bad copy/pasting on our part. Notice that the url had changed to 'fullcalendar/ajax/update/drop/', I changed that back too.

#40, see #1049080: Support non-Field API fields and relationships.

#42 thanks for this.
I'm not sure if it's exactly the same thing, as relationship allow to use fields that aren't directly linked to the base entity, but they still are fields.
However, the fix could be the sam for both.

I started to write something, currently only implemented on custom title and url but that may give some ideas ! And i can't go further without sleeping a bit (01:43 in France).

Meh, either open another issue or put it in #1049080: Support non-Field API fields and relationships.

Ok, works for me