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).
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 2011-10-24 04.29.31 pm.png | 54.96 KB | hyperglide |
| #17 | 2011-10-24 04.52.41 pm.png | 100.83 KB | hyperglide |
| #17 | 2011-10-24 04.53.17 pm.png | 30.83 KB | hyperglide |
| #14 | fullcalendar_classnames.jpg | 65.5 KB | aspilicious |
| #13 | fullcalendar_colors_classnames.png | 38 KB | aspilicious |
Comments
Comment #1
aspilicious commentedChanging status
Comment #2
aspilicious commentedThis patch adds array type hinting
Comment #3
aspilicious commentedThis 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.
Comment #4
aspilicious commentedAfter 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.
Comment #5
aspilicious commentedRetiteling.
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...
Comment #5.0
aspilicious commentedChanged info
Comment #5.1
aspilicious commentedMany ==> much
Comment #6
aspilicious commentedAdding tag
Comment #7
aspilicious commentedOk 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
is to specific... in fullcalendar.theme.css
If you can help me with that, we can close this topic.
Comment #8
aspilicious commentedForgot patch...
Comment #9
aspilicious commentedBumping 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.
Comment #10
hyperglide commentedReady to help test. Please confirm #8 is the latest patch please.
Comment #11
aspilicious commentedOk 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
Comment #12
hyperglide commented@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!
Comment #13
aspilicious commentedOk 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)
Comment #14
aspilicious commentedWhen you know the field name you can insert it into the UI and color it
Afterwards everything should be fine :)
Comment #15
aspilicious commentedIf 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 :)
Comment #16
hyperglide commentedUpdate --
>FullCalendar
>FullCalendar Colors
>Fullcalendar Colors Classnames
>Colors
admin/config/user-interface/fullcalendar/colors/classname, added and styled the color.Worked like expected! NICE JOB!
Looking it seems that
Fullcalendar Colors Fieldnameswill accomplish the same but using the drupal machine name, is this correct?Tried to get that working also but did not succeed.
Comment #17
hyperglide commentedSome Images to share:
Comment #18
aspilicious commentedThe 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.
Comment #19
hyperglide commented@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!
Comment #20
aspilicious commentedThe 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
Comment #21
hyperglide commentedRoger Roger. Thank you for your help and time!
Comment #23
tim.plunkettAwesome, one step closer to beta.
http://drupalcode.org/project/fullcalendar.git/commit/94bad42
Comment #24
aspilicious commentedPARTY!! now I can make my first real module =D
Comment #25
hyperglide commented@Tim GREAT!!!!
@Aspilicious Amazing work -- Keep it up!
What next?
Comment #26.0
(not verified) commentedcolors ==> fullcalendar colors