This is a must. We can't just keep adding module_exists for everything.

And before we do anything, we need to run it by merlinofchaos, so that we don't introduce a poorly designed new paradigm.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

aspilicious’s picture

Ok here is a starting patch, totally untested.
We also need an extra hook to parse the results if needed.

aspilicious’s picture

for some reason I don't get tabs slipped in... hmm srry for that

tim.plunkett’s picture

Status: Active » Needs work
+++ b/includes/views/plugins/fullcalendar_plugin_style_fullcalendar.incundefined
@@ -508,6 +516,29 @@
+    $fullcalendar_contrib = module_invoke_all('$fullcalendar_contrib_info');

No $ here.

+++ b/includes/views/plugins/fullcalendar_plugin_style_fullcalendar.incundefined
@@ -508,6 +516,29 @@
+      $arguments = array(
+        &$form,
+        &$form_state,
+        &$this,

Is this even valid? I see it in views_slideshow, but wow that looks weird.

+++ b/includes/views/plugins/fullcalendar_plugin_style_fullcalendar.incundefined
@@ -508,6 +516,29 @@
+        	'#type' => 'fieldset',
+         	'#title' => t('!module options', array('!module' => $fullcalendar_contrib[$module]['name'])),

:)

Also, I think splitting out the Colorbox form settings to /contrib/colorbox.fullcalendar_contrib.inc is a good test. We can decide later if we actually want to do that (since it would mean making its own fieldset).

aspilicious’s picture

Is this even valid? I see it in views_slideshow, but wow that looks weird.

Well thats the way to pass the form and formstate to the hooks. We reference the current form and formstate and throw into call_user_func_array

Also, I think splitting out the Colorbox form settings to /contrib/colorbox.fullcalendar_contrib.inc is a good test. We can decide later if we actually want to do that (since it would mean making its own fieldset).

Won't this cause conflicts if you alrdy had colorbox settings They will be lost. But anyway it's a good showcase

aspilicious’s picture

Ok, colorbox views settings, even the samewindow dependency, are working just need to remove the javascript from fullcalendar and load it in fullcalendar_colorbox.

I think this needs to be a seperate module even if it destroys the settings.

And why do you NEED a .module file before drupal sees your module ;)

aspilicious’s picture

Status: Needs work » Needs review
FileSize
7.37 KB

Stupid strange tabs... Now gone?

aspilicious’s picture

Sadly, the javascript examples in our api docs are incorrect, they just don't work :p. Options is not a function it's an array. And registerOptions doesn't exist at all.

So I had to figure it out myself but now I have one problem left, settings need to be passed to contrib js or it's kinda useless :p
Attached an almost finished patch, only the javascript part doesn't work because of the not existing settings.

tim.plunkett’s picture

Yeah adding it to Drupal.fullCalendar.options directly is always available, but registerOptions does exist!

http://drupalcode.org/project/fullcalendar.git/commitdiff/dd93fd9cccc2b0...

aspilicious’s picture

FileSize
10.03 KB

AAAH, I was not on the latest version...

So how can we pass the settings?

tim.plunkett’s picture

Here is a different approach, reusing the ctools_plugin stuff from fullcalendar_colors.
We'll have one module (currently named fullcalendar_contrib, but I'm thinking about fullcalendar_options) as a place to implement custom functionality, and an example for other custom modules.
I think MODULENAME.fullcalendar.inc is enough, especially since the hook is provided by fullcalendar.module itself.

tim.plunkett’s picture

This requires a cache clear, and for you to go to admin/config/user-interface/fullcalendar/options and hit save. I'll figure out automating that later. There will be a new fieldset called Extra Options now.

tim.plunkett’s picture

I forgot to switch colorbox to use the per-view setting.

tim.plunkett’s picture

Pushed a bunch more changes, I'm going to be adding some more support for other options in subsequent commits.
git clone --branch options-1326772 http://git.drupal.org/project/fullcalendar.git

tim.plunkett’s picture

Okay, so there is still an issue with the fullcalendar_options where ints become strings and bools become ints. But that's a Views bug, so we'll have to fix that separately.

tim.plunkett’s picture

aspilicious’s picture

MORE OPTIONS!
Here are some I made today.

The revert stuff doesn't work for some reason and the day and week views are kinda broken on my dev site. I get the feeling it's a fullcalendar plugin bug (looking at the js console)

aspilicious’s picture

FileSize
3.62 KB
aspilicious’s picture

Latetst branch doesn't work. Events aren't editable at all so I think your own made function is failing.
We also should set min and max time back to a width of 7.

tim.plunkett’s picture

Hm, works great for me. Not sure what you mean.

Also, we agreed we were sticking with integers only for now? The type cast code workaround doesn't let different types than the default value type.

tim.plunkett’s picture

Okay, this requires #1278580: $form['#submit'] not executed when the 'Apply' button is clicked inside a display options modal, since options_submit isn't receiving the form properly.

I moved all of the crazy logic out of fullcalendar.views.js (#1344836: Remove JS special processing). It's now really small and easy to read.

In addition, the processing in fullcalendar_get_settings() is now mostly handled by fullcalendar_fullcalendar_options_submit().

I added a weight to hook_fullcalendar_option_info(), but that only controls the order stuff is added to the form, I need a good way to have that also control the order that JS is processed.

aspilicious’s picture

Status: Needs review » Needs work

This still doesn't work...

In my view I:
- Disable weekends
- Diasbable all day
- Enable editing

==> results
- weekends still there
- all day still there
- can't drag and drop events
- day and week view still broken

aspilicious’s picture

New view is working it's the "old" one that brakes

tim.plunkett’s picture

Assigned: aspilicious » tim.plunkett

Okay, so upgrade path problems I can deal with :)

But c'mon Bram, how cool is the new code?!

tim.plunkett’s picture

Right, this comes back to the fact that views has no way of being updated from hook_update_N. I guess we need more init() code. Ugh.

aspilicious’s picture

:D I didn't had the time for serious revies so I didn't look at the code yet. But I think it's very cool ;)

tim.plunkett’s picture

Assigned: tim.plunkett » aspilicious
Status: Needs work » Needs review
aspilicious’s picture

FileSize
70.93 KB

Upgrading a alpha 7 site fails kinda hard :(.
I got the juery UI theme gone problem again.

When trying to resave the view I got the next error message
jqueryUI-fail.png

tim.plunkett’s picture

Okay, I fixed that error and I think I fixed the upgrade path. It worked for me all the way from 7.x-2.0-alpha7 to options-for-merge.

tim.plunkett’s picture

Unfortunately, that one commit came right after the Views 7.x-3.x-rc3, so this still requires Views dev.
#1278580: $form['#submit'] not executed when the 'Apply' button is clicked inside a display options modal

tim.plunkett’s picture

Assigned: aspilicious » Unassigned
Status: Needs review » Fixed

http://drupalcode.org/project/fullcalendar.git/commit/032e8aa

AWESOME!
Thanks so much for testing, aspilicious.

Automatically closed -- issue fixed for 2 weeks with no activity.