Problem/Motivation

The goal for this issue is to find a stable API for the fullcalendar module and the fullcalendar_colors module.
At the moment we have a nasty coupled API that has to much magic dust in it to be understandable by developpers.

To understand the problem you must understand the use cases and the modules needed to reach that goal.

1) Fullcalendar
Fullcalendar renders events in a jquery calendar. Each event can hold a list of css classes. These classes can be used to style the event (according to the info packed into the event)

2) Fullcalendar_colors
This module collects classes. The collected classes are passed to the colors module.

3) Colors module
Is a module consisting of a color configuration database and some api functions.
When a module passes a list of classes to the colors module, colors module will create and insert newly generated css for coloring the classes.

At the moment 1 and 2 are not rly seperated.

Use cases
Each possible solution to declutter the system must take care of the folowing use cases:

a) People should be able to add classes used by the fullcalendar module (for adding to the classes array)
b) People should be able to pass classes to the fullcalendar colors module so those classes will get passed to the colors module without being added to the classes array.
c) If a and b contain the same classes there should be a system to overcome the duplication

Possible real life use cases
- I want to add a class for the node type of the event (a)
- I want to color by node type for each event (a and b AND c)
- I want to color an event, the class is alrdy contained in the classes array so I don't need to add it. This happen for example when you like to color a gcal calendar. (b)

Proposed resolution

1) Use the existing fullcalendar_classes and fullcalendar_classes_alter for task (a)
2) Use fullcalendar_colors_class_names (better name needed?) to collect the aditional classes (b)
3) Avoid the duplication (c) of (a) and (b) by passing the classes fetched by (a) through (b) IF
- fullcalendar colors module is enabled
- there is an existing color configuration for that class in the colors database

Remaining tasks

- Review the patch
- Fix the TODO's
- Write a handbookpage with usefull examples and good explanation of the use cases and the solutions needed for those use cases

API changes

- If you need only (a) nothing changed
- If you need only (b) nothing changed (compared with the dev version)
- If you need (a) en (b), you should only implement (a).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

aspilicious’s picture

Status: Active » Needs review

Changing status

aspilicious’s picture

This patch adds array type hinting

aspilicious’s picture

This is maybe a better idea. Code probably doesn't work because of the ctools plugins.

I used css_selectors to proove a point, name is debatable.

aspilicious’s picture

After discussion with timplunkett 10 days ago and some thinking on my vacation I come with this solution. This splits the fullcalendar_classes hook and the fullcalendar_colors_class_names hook.

hook_fullcalendar_class
Is a hook for adding css classes to the fullcalendar event. You can use the entity to decide which classes to add.

*** IMPORTANT CHANGE ***
If fullcalendar colors is enabled every classname that has a color configuration in the color database will be colored.

hook_fullcalendar_colors_class_names
Collects additional classes for coloring that are NOT in the classes array of the fullcalendar event.

*** IMPORTANT CHANGE ***
Classes that are alrdy added with the hook_fullcalendar_classes DO NOT need to be added again with the fullcalendar_colors_class_names hook.

These changes give the needed flexibility to developers AND prevent duplication of code.

Sidenote: this issue does not try to move more code to the colors module. That's a different issue that needs more discusion. This issue tries to stabilize the api for a beta release.

aspilicious’s picture

Title: Reintroduce class argument » Stabilize fullcalendar (colors) api for beta release

Retiteling.

Just a note: when I was writing the patch I wondered if I should use module_invoke_all or the construction I'm using now (same as we alrdy have in the fullcalendar colors module). I thought my code was ugly but aparantly for this use case this is the correct solution. See http://drupal.stackexchange.com/questions/8159/is-it-better-to-use-modul...

aspilicious’s picture

Issue summary: View changes

Changed info

aspilicious’s picture

Issue summary: View changes

Many ==> much

aspilicious’s picture

Issue tags: +beta blocker

Adding tag

aspilicious’s picture

Assigned: Unassigned » tim.plunkett

Ok new tested and finished patch. Assigning to the boss for a review.

Couple of ways to test this:
1) Look at the code
2) Test if coloring still works as expected

3) THA AWESOME STUFF

- add a specific classname to a gcal field
- install fullcalendar_colors_classname module
Instructions ==> http://drupal.org/node/1175528/git-instructions/classnames/nonmaintainer
- update colors module to latest dev
- create a color configuration for the new gcal class in the UI
- LOOK AT THE PRETY COLORS!!!

Sidenote:

Text coloring is failing because

/* Undo Drupal default theme link colors */
.fc-content a:link,
.fc-content a:visited {
  color: #fff;
  text-decoration: none;
}

is to specific... in fullcalendar.theme.css

If you can help me with that, we can close this topic.

aspilicious’s picture

Forgot patch...

aspilicious’s picture

Bumping this to the top of my list.

Tim could you review the code for this after the others got in?
(don't look at the trailing whitespace issues)

Probably needs a reroll.

HyperGlide’s picture

Ready to help test. Please confirm #8 is the latest patch please.

aspilicious’s picture

Ok I rerolled the patch.

1) Download the "to-merge" branch and see if you can upgrade to that one, its possible that things brake due to missing handlers, but after runnin update.php and clearing caches everything is fine again

2) Install this patch

3) Install fullcalendar_colors_classname module
Instructions ==> http://drupal.org/node/1175528/git-instructions/classnames/nonmaintainer

4) update colors module to latest dev

5) Create a new color configuration in the colors UI. (you need firebug or chrome development tools to check the date class name added to the event, that classname is the selector you need)

If you need more help I'm sometimes available on irc in the #fullcalendar channel

HyperGlide’s picture

@aspilicious

You lost me at "Download the "to-merge" branch" I assume you are talking about downlaods here http://drupalcode.org/project/fullcalendar.git

Thanks!

aspilicious’s picture

Ok lets make it easier to test this :)

Download the attached zip file.
- It contains a modified fullcalendar module (based on alpha 7 so run update.php when upgrading)
- It also contains the "fullcalendar colors classname" module

Add some events containing a date field. Search for the date field classes added for a specific event.
In my test setup I created a date field named "field_datum". Fullcalendar module inserted the "fc-event-field-field_datum" class for this field. (see image)

fullcalendar_colors_classnames.png

aspilicious’s picture

FileSize
65.5 KB

When you know the field name you can insert it into the UI and color it

fullcalendar_classnames.jpg

Afterwards everything should be fine :)

aspilicious’s picture

If it wasn't clear, I'm done with coding.
I fixed a couple small bugs while testing so I think it's bugfree.

I see I alrdy assigned it to you :)

HyperGlide’s picture

Update --

  1. Loaded the zip with the (2) modules onto the test site.
  2. Also had to go and get -- http://drupal.org/project/colors (used the alpha 2) as it had the most recent date.
  3. Enabled the following modules in all:
  4. >FullCalendar
    >FullCalendar Colors
    >Fullcalendar Colors Classnames
    >Colors

  5. Went to run update.php and get an error that "Fullcalendar_color" was missing. Weird it was showing in my modules page. I went back and poof was gone. Disabled all, uploaded agin and was back.. weird. Perhaps this was caused because I tried to have a peak at the admin pages before applying the patches. Disabled all in modules admin and than.
  6. enabled again and ran update.php
  7. Loaded the page that had a views calendar block, using firebug got my class names.
  8. Went back to admin/config/user-interface/fullcalendar/colors/classname, added and styled the color.

Worked like expected! NICE JOB!

Looking it seems that Fullcalendar Colors Fieldnames will accomplish the same but using the drupal machine name, is this correct?

Tried to get that working also but did not succeed.

HyperGlide’s picture

Some Images to share:

After update.php

Setting Up The Admin

Node display.

aspilicious’s picture

The fieldname stuff is an example module to proof you can color based on the output of a select field.
I renamed to fullcalendar_colors_classnams_example but forgot some things :)

This example module won't be included in the final product. Probably will place it on a doc page.

HyperGlide’s picture

@aspilicious -- gotya.

So anything more I can do? How much more testing do we need for a commit to the published dev or alpha.x branch?

Keep up the awesome work!

aspilicious’s picture

The thing needs a code review from Tim Plunkett and he decides what gets in and what has to be rewritten :)
So we have to be patient :).

If he is happy this will be merged into the next release

HyperGlide’s picture

Roger Roger. Thank you for your help and time!

tim.plunkett’s picture

Status: Needs review » Fixed
aspilicious’s picture

PARTY!! now I can make my first real module =D

HyperGlide’s picture

@Tim GREAT!!!!
@Aspilicious Amazing work -- Keep it up!

What next?

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

Anonymous’s picture

Issue summary: View changes

colors ==> fullcalendar colors