-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTMLCalendar allow custom classes #74281
Comments
At the moment methods like HTMLCalendar.formatmonthname and HTMLCalendar.formatmonth have hard coded name 'month'. This class is pretty helpful as a good start, but if you want to customize I think it would be helpful for others too, if this would have be customize able. Would you accept a PR for such thing? |
Can't you override the |
Of course I can, but I can't add multiple css classes, and I forced to |
IMHO this could all be done by overwriting the relevant methods. But this might be overkill. I think a solution might be to move the CSS classes into class attributes of HTMLCalendar. Customizing the CSS classes would then be done by subclassing HTMLCalendar and overwriting the appropriate class attributes. Is this what you had in mind? |
@doerwalter, exactly. I found myself overwriting the relevant methods too many times. I usually did something like this: class WorkCalendar(HTMLCalendar):
def formatmonthname(self, theyear, themonth, withyear=True,
style=r'class="month-head"'):
"""
Return a month name as a table row.
"""
monthname = super().formatmonthname(theyear, themonth, withyear)
regex = r'class\="month"'
return re.sub(regex, style, monthname, 1) Using class attributes would nice, also considering that the days CSS classes are defined as class attributes. My intention was a few more class attributes (for the month header, and month) and also change the existing code such that each day can have multiple CSS classes and not just one. I am willing to work on a PR for that if that sounds good and there is someone who would be willing to merge it. |
... Using class attributes would nice, also considering that the days CSS classes are defined as class attributes. I meant to write : Using class attributes would be nicer, also considering that the days CSS classes are defined as class attributes. |
OK, go ahead. I'm looking forward to what you come up with. |
I implemented two possible solutions. Chronologically speaking V2 was implemented before V1, but it's a bit über-smart and might surprise it's The first version is my current preferred solution. I intentionally didn't create a PR for that yet. These are the branches: https://github.com/oz123/cpython/tree/issue30095-v1 |
The second link is a 404. For the v1 patch: The variable names are a bit inconsistent: The first uses "classes" all others use "styles". This should be consistent within itself and with the existing code, i.e. "classes" should be used. Also each class attribute should be preceded with a comment, explaining what the CSS class is used for. As these are now made public to be overwritten by subclasses, I wonder wether it would make sense to document these class attributes in Doc/library/calendar.rst |
I agree with you about consistent naming. Personally, I would prefer to name all the variables "styles". But I preferred not to break past compatibility too. So I guess we are stuck for a while with "classes". I will rename the variables. As for documenting that, I would also do that. |
Apparently, I forgot to push the second branch. It is now pushed. I renamed the class attribute names on the v1 branch. I still need to do
|
I implemented your suggestions plus the obvious tasks of adding tests and documentation. Would be happy to hear your feedback. |
See comments on Github |
See my comments on the pull request: #1439 After you address those, IMHO this is ready to be merged. |
See comments on the pull request. Also it seems that currently the pull request can't be merged because of merge conflicts. |
@walter, I fixed the issues your raised, and also solved the merge conflict in What's New. |
Closing the issue. The patch has been merged. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: