Add support for field row style

Another reason for this would be the ability to use semanticviews's row style.

This is definitely going to come after #992812: Date field discovery code fails on edge cases, but then it is the top priority.

Discussion:
Should there be a 6.x-1.0 release before this gets resolved?
On one hand, a stable release might attract more attention to the issue queue.
On the other, the module might get written off for not supporting fields as a row style.

So, how would this work exactly? I have the code "working", but I really don't know how this would function.

For one, it would require a direct hack against the fullcalendar.js, which goes against the intent of #980886: Require Libraries API.

And even when you add extra fields, the visible part of an event is dictated by its length. In calendar.module, events stretch vertically to fit their contents, but that would defeat the purpose of fullcalendar.

If anyone has ideas or mockups or anything, I'd appreciate it.

I'm not sure if I would want to allow row styles yet—I think getting out a 1.0 release should be a higher priority for now. Rows are a hairy beast, and might end up holding back a release for some time.

I haven't needed this feature yet... and I haven't needed it on any of my sites where I use calendar.module (yet) either. It would be an amazing feature to have, to be sure, but I don't think it's essential. Not many online calendaring solutions support more than a title field in the graphical calendar listing, anyways.

After playing with this more and more, I just don't see this happening before a 1.0 release, especially because it would require changes to fullcalendar.js.

I would still appreciate descriptions of use cases though, that would help me code it.

In the short term, geerlingguy suggested mimicking the auto-discovery of the date field, by allowing a specific field to be used in place of the title. I really dislike the UX of this, because it really is awkward to use the machine name, but I think its a good temporary solution.

In the long run, I envision the fields row setting to allow one field to be marked Title, one to be marked Date, and have the rest only show up on the fallback display. The limitations of the jQuery prevent any other fields from being added. However, this would allow use of either views_customfield or computed_field, which at leasts provides the possibility of adding your own info.

I like your long-run plan - being able to use a simple field as the Title would be enough to satisfy pretty much any case, because the user could then put whatever data he wants into the computed or custom field... of course, if you have more than 5-10 words in an event title, you're going to need a huge display to prevent a really tall calendar!

Something like this?
If a the chosen field is empty on a particular node, the title is used instead.

Exactly. Don't have time to test right now, but it looks like that should be adequate for almost any use case. UI could be more intelligent - would be nice if you could simply have a popup selection field with all fields listed, and the user could choose one. (Same could be said for the URL field).

If this was going to be a longer-term solution I would do a select list. But I think it'd be better to just get this in and then focus on the fields row style.

If you could give this a quick run through and an RTBC, that'd be awesome.

I started to work on #910470: Empty text, but it was conflicting with #999158: Improve fallback display, which also conflicted with this.

Sooooo, here's all three at once. They are very tightly intertwined, I really couldn't break it up more. Sorry!
I'll post a step-by-step account of what went on later.

Hm, there was some cruft in that last patch. Try this one!

These should probably be comments in the code. Here they are now as an explanation.

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -114,6 +114,13 @@ function fullcalendar_theme() {
+    'fullcalendar_link' => array(
+      'arguments' => array(
+        'node' => NULL,
+        'attributes' => NULL,
+        'index' => NULL,
+      ),
+    ),

Register the new theme function.

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -136,6 +143,10 @@ function theme_fullcalendar_classname($n
+  if (isset($vars['view']->empty)) {
+    $vars['empty_text'] = $vars['view']->empty;
+    return;
+  }

Set the empty text if the display says there are no events.

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -146,29 +157,31 @@ function template_preprocess_views_view_
-  $vars['editable'] = _fullcalendar_update_access($node);
-  $vars['className'] = theme('fullcalendar_classname', $node);
+  $node->editable = _fullcalendar_update_access($node);
+  $node->class = theme('fullcalendar_classname', $node);

Adding these to $node instead of $vars means they can be easily accessed later in the code.

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -146,29 +157,31 @@ function template_preprocess_views_view_
-  $index = 0; // Used to create $vars['data'] variable.

No longer needed, see below.

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -146,29 +157,31 @@ function template_preprocess_views_view_
+  $node->url = 'node/' . $nid;
+  if ($url_field = $vars['options']['fullcalendar_url_field']) {
+    if (isset($node->{$url_field}[0]['value'])) {
+      $node->url = $node->{$url_field}[0]['value'];
     }
   }
-  if (empty($vars['url'])) {
-    $vars['url'] = url('node/' . $nid);
-  }

No longer call url() right away, so it can be passed through l().

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -146,29 +157,31 @@ function template_preprocess_views_view_
+  $title_field = $vars['options']['fullcalendar_title_field'];
+  if (!empty($title_field) && !empty($node->{$title_field}[0]['value'])) {
+    $node->title = $node->{$title_field}[0]['value'];
+  }

If a valid field has been selected, replace the node title with its value.

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -146,29 +157,31 @@ function template_preprocess_views_view_
-        $vars['data'][$index] = _fullcalendar_set_display_times($node, $field_name);
-        $vars['data'][$index]['index'] = 0;
-        return;
+        $attributes = _fullcalendar_set_display_times($node, $field_name);
+        $vars['data'][] = theme('fullcalendar_link', $node, $attributes);
+        $display_field = array();
+        break;

Calling return now is unnecessary special-casing. Emptying $display_field allows it to skip the later foreach().

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -179,12 +192,11 @@ function template_preprocess_views_view_
-    foreach ($node->$field_name as $key => $item) {
-      $vars['data'][$index] = _fullcalendar_set_display_times($node, $field_name, $field, $item);
-      $vars['data'][$index]['index'] = $key;
-      $index++;
+    foreach ($node->$field_name as $index => $item) {
+      $attributes = _fullcalendar_set_display_times($node, $field_name, $field, $item);
+      $vars['data'][] = theme('fullcalendar_link', $node, $attributes, $index);
     }
-    return;
+    break;

No need to return, break is fine. In case other code needs to be added to the end of the function.

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -216,13 +228,29 @@ function _fullcalendar_set_display_times
-    'start' => date_format($date1, DATE_FORMAT_DATETIME),
-    'end' => date_format($date2, DATE_FORMAT_DATETIME),
-    'start_formatted' => date_format_date($date1),
-    'end_formatted' => date_format_date($date2),
+    'start' => $date1,
+    'end' => $date2,
+    'nid' => $node->nid,
+    'cn' => $node->class,
+    'title' => $node->title,
+    'class' => 'fullcalendar_event_details',
+    'editable' => $node->editable,

Use this function to only set up the values needed by fullcalendar.js, the date values can be computed later.

+++ fullcalendar.module	16 Dec 2010 22:32:05 -0000
@@ -216,13 +228,29 @@ function _fullcalendar_set_display_times
+function theme_fullcalendar_link($node, $attributes, $index = 0) {
+  $text = date_format_date($attributes['start']);
+  if (!$attributes['allDay']) {
+    $text .= ' to ' . date_format_date($attributes['end']);
+  }
+
+  $attributes['index'] = $index;
+  $attributes['start'] = date_format($attributes['start'], DATE_FORMAT_DATETIME);
+  $attributes['end'] = date_format($attributes['end'], DATE_FORMAT_DATETIME);
+
+  return l($text, $node->url, array('attributes' => $attributes));
+}
+

Moving this into a theme function allows overriding of the fallback display, or last minute hacks into the attribute of an event.

+++ fullcalendar.views.inc	16 Dec 2010 22:32:05 -0000
@@ -10,7 +10,31 @@
+  $path = drupal_get_path('module', 'fullcalendar');
+  $views_path = drupal_get_path('module', 'views');
   return array(
+    'display' => array(
+      'parent' => array(
+        'no ui' => TRUE,
+        'handler' => 'views_plugin_display',
+        'path' => "$views_path/plugins",
+        'parent' => '',
+      ),
+      'page' => array(
+        'handler' => 'views_plugin_display_page',
+        'path' => "$views_path/plugins",
+        'parent' => 'parent',
+      ),
+      'fullcalendar' => array(
+        'title' => t('FullCalendar'),
+        'handler' => 'views_plugin_display_fullcalendar',
+        'help' => t('For use with FullCalendar style'),
+        'path' => $path,
+        'parent' => 'page',
+        'theme' => 'views_view',
+        'uses hook menu' => TRUE,
+      ),
+    ),

Our new display plugin inherits from the generic page display.

+++ fullcalendar.views_default.inc	16 Dec 2010 22:32:05 -0000
@@ -0,0 +1,52 @@
+ * Implementation of hook_views_default_views().
+ */
+function fullcalendar_views_default_views() {

This is a default view, which shows that you should use the display, style, and row plugins, as well as setting the empty text.

+++ views-view-fullcalendar.tpl.php	16 Dec 2010 22:32:05 -0000
@@ -21,11 +21,13 @@
+  <?php if (!empty($event)): ?>

Don't print empty divs (nodes that meet the views filters but don't have date fields).

+++ views-view-fullcalendar.tpl.php	16 Dec 2010 22:32:05 -0000
@@ -21,11 +21,13 @@
+  <div class="fullcalendar_event">

Move the .fullcalendar_event div here to wrap around repeating events

+++ views-view-node-fullcalendar.tpl.php	16 Dec 2010 22:32:05 -0000
@@ -19,19 +19,14 @@
+<?php if (isset($empty_text)): ?>
+  <?php print $empty_text; ?>

If there are no events, say so.

+++ views-view-node-fullcalendar.tpl.php	16 Dec 2010 22:32:05 -0000
@@ -19,19 +19,14 @@
+  <h3 class="title"><?php echo $node->title; ?></h3>

For each event, display the title, which may have been overridden.

+++ views-view-node-fullcalendar.tpl.php	16 Dec 2010 22:32:05 -0000
@@ -19,19 +19,14 @@
+    <div class="fullcalendar-instance">
+      <?php print $row; ?>
+    </div>

Print each repeating date wrapped in a div.

+++ views_plugin_display_fullcalendar.inc	16 Dec 2010 22:32:05 -0000
@@ -0,0 +1,20 @@
+class views_plugin_display_fullcalendar extends views_plugin_display_page {
+  function render() {
+    if ($this->view->total_rows == 0) {
+      $this->view->result[] = new stdClass();
+      $this->view->empty = $this->render_textarea('empty');
+    }
+    return parent::render();
+  }
+}

If the view has no result, create a dummy node to force the calendar to display anyway.

Powered by Dreditor.

Rerolled after #1001688: Move jQuery out of template file.
I removed the default view. It can come later.

Also, I named the new plugin according to the proper convention (fullcalendar_plugin_display_page.inc instead of views_plugin_display_fullcalendar.inc). See #1003602: Rename views plugins and reorganize files for renaming the existing files.

This is the last real issue before a release, please review!

Patch applied correctly, field setting works correctly. No problems whatsoever.

Only a minor suggestion: in the row style settings, add an example to the title field, just like you have for the URL Field:
For example "field_event_title" Setting to needs work, but in reality, it's RTBC once you make that UX change.

See attached for visual example.

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

Setting back to active for future possible field row style implementation.

Actually I'm marking this fixed. If someone has some ideas and mockups of how a fields row style would work, please open another issue.

I think this should be marked as won't fix for now, as current status gives the impression that field row style is supported.

For me the problem is that you can't tweak the title like you could with a field style. I'd like to be able to rewrite the title to add tokens or something, or add a taxonomy term to the calendar item somehow. I guess I'll look into overriding the title in the theme layer or with nodeapi.

Please don't adjust issue statuses after closed (fixed).

Also, in the 7.x-2.x branch, we've fully switched to field styles.

Apologies - since it was set automatically, I thought I was correcting an oversight.

Thank you for your hard work.