Problem/Motivation
All of the functionality from the Date module that Calendar relies on did not make in it into core for 8.0.0 release. More functionality is being worked for 8.1 and beyond that Calendar will need.
#2613454: Port Date module functionality missing from 8.x core has been created by @pjonckiere to see about adding missing functionality to 8.x version of Date module.
Some of the missing functionality may get into Date 8.x but other functionality might go directly into core for 8.1.
If we wait for 8.1 that majorly delay Calendar Drupal 8. On the other hand if we duplicate functionality it will be a pain to update Calendar when 8.1 arrives.
Proposed resolution
We create a submodule of this module called calendar_datetime to temporarily hold functions and class that will be added to the core in 8.1.
This should be much easier to do because of the Object Oriented nature of Drupal 8.
From the purposed readme:
This module simply holds classes and other functions that will will be later
added to Drupal core DateTime module(or possibly contrib Date module). Each class
or function should have a reference to the Drupal core issue where it came from.Ideally these classes should come directly from RTBC core datetime issues that
will be added in later 8.x point releases(8.1, 8.2, etc).Once they have been added to core they can be removed from this module and the
main Calendar module should only have to change "use" statements for classes or
change function calls from "calendar_datetime_*" to "datetime_*" **without other
programming changes**.
For example will probably need the extra Views arguments in #2567815: Add week, date, and year-month Views argument plugins
I will provide a patch in this issue the adds calendar_datetime with simple the arguments from this issue.
Remaining tasks
Figure out datetime functionality is going to be in 8.1 that we need. Also figure what is missing and try to help get it into 8.1.
API changes
Drupal\calendar\CalendarHelper may not be needed.
Comment | File | Size | Author |
---|---|---|---|
#4 | calendar-purposed_solution_for-2615120-4.patch | 6.14 KB | tedbow |
Comments
Comment #2
tedbowComment #3
tedbowUploading patch that creates calendar_datime module and adds classes from #2567815: Add week, date, and year-month Views argument plugins
to it.
Comment #4
tedbowWhoops fixed empty patch
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedWhile this approach makes a lot of sense, I feel like the calendar module is the wrong place to do it. I think that a lot of the functionality we need should eventually live in the ported date module and thus we should add the submodule there. Unless I'm missing something?
Anyway, we really should get the porting of the date module going again...
Comment #6
tedbow@pjonckiere yeah I am all for porting functionality to the Date module. I just wondering for the functionality that already has issues that are going to get into core 8.1.
The other thing I am wondering about is coordinating 2 dev modules Date and Calendar might slow down development of Calendar.
Hopefully we will hear back from the date maintainers soon. If so maybe it would make sense putting effort into getting everything that is need for Calendar into Date and then getting back to Calendar after that. The problem might be that we don't everything that Calendar needs until we go through. So that would mean a lot of back and forth between the two modules and if they are different maintainers that could be very slow.
Another variation on my idea would be to make calendar_date which would just be a holding area while are developing for things that will go into Date(not core Datetime).
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedI already pinged mpdonadio (maintainer of datetime in core) in the hopes he would know something more about the porting status. Unfortunately he doesn't, see #2613454: Port Date module functionality missing from 8.x core. So I was about to ping the maintainers themselves, but the list is quite big. I'm not sure who we want to address (the ones with the most commits? the ones with the most recent commits?).
So yeah... we probably don't want to waste any more time. As a pragmatic approach, I like the idea of the calendar_date (and possibly a calendar_datetime) submodule that we can gradually port back as we go. I don't like the idea of doing twice the work, but it might be the only way of unblocking a lot of work for now.
So what I think we should do is:
- follow #2543958: [META] DateTime Module Improvements closely to have a good idea of what will make it into core. And add that behaviour to a calendar_datetime submodule.
- comment in #2613454: Port Date module functionality missing from 8.x core that we will make a submodule for behaviour that actually belongs in the date module. If someone would step up to port the date module, we can make patches to move the behaviour at any time. Versioning might be a concern here, but we can decide on that once we are there.
- start porting the functionality we need in a calendar_date submodule. For now, I would try to keep that to a minimum though. I can imagine that some functionality (e.g. end date) will be picked up shortly after the full release. That could be a trigger for the date module porting to gain momentum. If not, we could simply keep adding stuff and decide later on how we handle things.
Thoughts?
Comment #8
tedbow@pjonckiere sounds like a good plan to me. Hopefully this is just a temporary situation.
Me neither but hopefully will won't be doing all that much more work. Hopefully we will be pulling in patches done in core and then extra work we do that isn't in core would have to be done by someone anyways. For the new work we do in calendar_date hopefully it will find a better home before too long.
Comment #9
tedbowadding tag to relate all issues that deal with this submodule
Comment #10
tedbowMarking as fixed because calendar_datetime is not in module