Hey all! I emailed KarenS about possible work on the date module, and the following is a summary of what we came up with. I'll post more details/respond to discussions if people think this is a viable proposal.
About Me: I am a current college sophomore concentrating in physics and math with a computer science secondary. I am an experienced Drupal developer, having worked with Development Seed for two years now in both Drupal 5 and 6. I have a lot of experience with the date module, as well as relevant areas such as Views 2, CCK, and FormAPI. I have submitted patches to many modules including date and views, the most relevant to this work being an outstanding one adding flexible granularity to the current dates: http://drupal.org/node/259308.
Overview: There are a number of areas KarenS and I discussed as possible options for a summer of work. The primary ones include refactoring the API to be more understandable, cleaner, and to use OO techniques where applicable. I think significant gains in simplicity and extensibility are possible here, which would be very useful for such an important module used in many other applications. Another is reimplementing the submodules in this light. A third is finishing flexible granularity and other additions on top of the API. All this will probably be done in the context of the update of Date module to Views 3 and Drupal 7.
Details:
1) Refactoring much of the API for the next Drupal7/Views3 release cycle, including more object oriented and streamlined design that would enable additions such as the flexible granularity patch to go much more smoothly. From my work with the date module I have identified and experienced both its strengths and weaknesses, and I think I am in a good position to undertake some rearchitecting.
2) Refactoring the implementing modules including the Date CCK fields, input fields, etc to use this new API and to become more pluggable and extensible themselves. Much of the architecture has become somewhat brittle due to the wide variety of use cases that have been included. I would aim to eliminate or marginalize non-core functionality when possible to allow for a more easily understood, compact module and set of submodules.
3) Finishing and committing the implementation of flexible granularity, including sorts, views integration, etc.
Possible Mentors:
Karen Stevenson, possibly an additional person if she is short on time.
Comments
The big thing here is that we
The big thing here is that we need an outline of exactly what refactoring will be done, just saying 'make it better' is not very clear. I also do not want to 'eliminate or marginalize non-core functionality' because there are people using those things.
What I DO think would be a good goal, and maybe what you are trying to say, is to pull out some basic functionality that could be reworked into a nice, clean basic date API, and then rework all other functionality in the Date and Calendar module to build on that API. The goal would be coming up with a base API that could go into core in D8 -- something that is neat, clean, extensible, and that will cover all the core use cases for dates and which can easily be extended to do at least all the things the current contrib module can do.
This is a HUGE project, but would be a good goal. What concerns me is there is a ton of crazy edge cases that have to be accommodated -- the current complexity is because people need all these things. It is much more complicated to do this than it might appear. As the API is created, you would have to be sure that it can still accomplish all the things we can do now.
If you change the API someone has to change all the rest of the code to use the new API. And someone has to write an update path for the current data, if any of that changes. I don't want to end up with a new API that does some basic things but breaks everything else leaving me to try to fix all those other things myself.
I'm also concerned that this may not be a one-person project, nor one that fits neatly into Summer of Code -- it will take more than one person and probably more than one summer. I don't know how to break it down into a realistic Summer of Code project.
So I'm totally on board with making a better Date API, I'm just not sure exactly how to structure a Summer of Code project to do it.
New student proposal, submitted on Google SoC site
About Me: I am a current college sophomore concentrating in physics and math with a computer science secondary at Harvard University. I am an experienced Drupal developer, having worked with Development Seed for two years now in both Drupal 5 and 6. I have a lot of experience with the date module, as well as relevant areas such as Views 2, CCK, and FormAPI. I have submitted patches to many modules including date and views, the most relevant to this work being an outstanding one adding flexible granularity to the current date API: http://drupal.org/node/259308.
Overview: This project aims to simplify, generalize, and clean up the base date API for Drupal 7 and beyond, creating a fresh API that pays refactoring debt and provides a solid foundation moving forward. I would aim for easily understood, extensible, and simple basic date handling workflow, with the ability for special cases and additional functionalities to be appended cleanly and without obfuscating the core functionality. As many implementing modules as time permits would be ported to this new base API.
Description: This project would begin by working with KarenS on understanding and implementing the new Date API for Drupal 7 and Views 3. Once this is in a stable state, I would begin reimplementing the core API using the old one as a guide, but rearchitecting for primarily:
1) object oriented, simplified and unified workflow from input to storage to output. Currently, many of the different input and output fields do much of their own handling, parsing, and verification. This vastly complicated the addition of flexible dates, for instance, and made it much harder to grasp the fundamental versus redundant functionality when working on the project. 2) Support for flexible granularity and other standards-based date functionalities and extensions. I would study standard implementations of date handling in other languages and situations to determine best practices here.
I would first develop a detailed roadmap and schematic plan for the new module, and then code the base API. From here, I would port core date modules, including at least the basic CCK/Views/Input layer implementations, to this new API, ideally with significant gains in simplicity and code brevity from the new workflow. I would also keep an eye towards support for flexible granularity in this new API, which has been a recurring request for the Date module for some time now. This new API would ideally be readied for a release for Drupal7 to which other implementing modules would eventually be migrated; early adopters would be developers, until a critical mass is achieve for it to largely supplant its predecessor (similar to the Views development and release cycle, for instance).
Date module is used across drupal, and thus even though it is functional, an update that increases simplicity and reliability of the basic workflow would be extremely useful and helpful to countless developers who need to extend and implement this module. Having done a lot of development with Date, in Views, Feeds, and in the Date module itself, I think I am in a good position to update it. Giving other developers a simpler, more reliable and predictable date handling API would be very useful in countless applications across Drupal.
Mentors:
Karen Stevenson
Perhaps others. I will be in the Washington, DC and New York City areas for most of the summer.
Dmitri Gaskin - main mentor
Greg Dunlap - Backup mentor
ALocalMentor - a local mentor, who lives/works near the student and who will meet with the student in person at least two times over the course of the Summer of Code.
Difficulty: Hard