embedded media video provider notes

Nice bootstrap guide in emfield/contrib/emvideo/...easy to get started. CCK needs one of these.

validation hook isn't implemented in the example, but is called from emfield module.

Posted via email from dsayswhat's posterous

views hooks to fix calendar display

Ran into a difficult bit of work today -

Views in Drupal based on the Calendar and Date modules are nifty, except when it comes to how you display recurring items.

On views fields, the 'group multiple values' settings don't allow you to set your 'show 1 value starting from' to correspond to the arguments which have been passed to your view.

That means you get the next item, even if it's outside the bounds of the argument driving your month, week or day view.

That's ugly, cause you'll get Sept 4th sandwiched between Aug 12 and Aug 15, since the event already happened, so it jumps forward to the next recurrence, but shows it in the original place on the month view. Ick.

Turns out I had to use hook_views_pre_render() to sift the $view->results array for nodes that were within the bounds of my arguments...here's the code:

function xxx_views_pre_render(&$view) {

// we want to exclude search results from this treatment - but the other calendar displays ( week, day, month ) seem to benefit

if ($view->name == 'eventcalendar' && $view->display_handler->display->id != 'page_2' ) {

// set our date arguments to unix timestamps for comparison with row data.

$startwindow = strtotime($view->date_info->min_date_date);

$endwindow = strtotime( $view->date_info->max_date_date );

foreach ($view->result as $key=>$row) {

$eventdate = strtotime($row->{yourDateFieldHere});

if ( $eventdate >= $startwindow && $eventdate <= $endwindow ) {

// our event is within the window set by the arguments to our view.

$newresult[] = $row;

}

}

$view->result = $newresult;

}

}

Another interesting point to note is that it seems ( at least on this view, need to verify elsewhere ) that $view->current_display is always set to 'calendar_period_2'. That's the month view...but it's set to that even if you're on week or day. That may be a function of the default display for the calendar? need to look into that further.

That meant I couldn't reference $view->current_display to include/exclude certain displays from my hook. I had to go deeper into the $view->display_handler object to get what I was looking for: found it at $view->display_handler->display->id.

Posted via email from dsayswhat's posterous

custom cck field development

Reference material: cck hook docs found here: http://drupal.org/node/342987,
Karen Stevenson (http://www.lullabot.com/articles/creating-custom-cck-fields)
Jennifer Hodgdon (http://poplarware.com/articles/cck_field_module)
link and cck/optionwidgets modules

GOTCHAS:

Gotcha #1
// implementation of hook_field_info

function classnote_degree_field_info() {
return array(
'degree' => array(
'label' => t('Degree'),
'description' => t('Stores a degree with the year it was earned.'),
)
);
}

// implementation of hook_widget_info

function classnote_degree_widget_info() {

return array(
'degree' => array(
'label' => 'Degree/Year selector',
'field types' => array('degree'),
'multiple values' => CONTENT_HANDLE_CORE,
'callbacks' => array(
'default value' => CONTENT_CALLBACK_DEFAULT,
)
)
);
}

if field_type in hook_widget_info doesn't match an array key from hook_field_info, your field won't show up in the cck | manage fields UI.

GOTCHA #2:

function classnote_degree_field_settings($op, $field) {
switch ($op) {
case 'form':
$form['initial_year'] = array(
'#type' => 'textfield',
'#title' => t('What year did you begin awarding degrees?'),
'#size' => 10,
'#default_value' => $field['initial_year'] ? $field['initial_year'] : date('Y')-50,
'#required' => TRUE
);

...

#default_value needs a ternary operator or variable that's set before the form definition, or else you'll lose your previous settings when the edit form loads.

---

My preferred order of operations is to get the ui piece of it working first...

Bits related to the node edit form

hook_field_info() is needed to get the datatype available to the manage fields interface.

hook_field_settings() to define database tables
note: if this isn't defined, nowhere to save the data.

hook_widget to define the form elements in node_edit form
Note:

Then think about making the options configurable...

hook_field_settings()::op=database columns handles database storage

hook_field()::op=validate does the form validation.

CCK does no checking to see if the various parts are consistently implemented - doesn't look at db fields and see if they match fields in code, for example. That means you can make a false start, don't clean it up cause you don't understand the database tables are orphaned, and then change your code and you can't figure out why it doesn't save...no fields to save to.

CCK makes new tables PER FIELD INSTANCE - add a field, make a table. So if you make changes to your cck field module, delete your cck fields and start over in your content type.

Posted via email from dsayswhat's posterous