Skip to content
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

Daterangepicker #2804

Closed
wants to merge 4 commits into from
Closed

Conversation

samuelyeewl
Copy link
Contributor

I added a DateRangePicker widget, for when you only want a datetime.date range rather than a datetime.datetime range.

@samuelyeewl samuelyeewl closed this Oct 7, 2021
@philippjfr
Copy link
Member

@samuelyeewl Do you still want to add this? I think it's reasonable to add although we might consider making DatetimerRangePicker more configurable.

@samuelyeewl
Copy link
Contributor Author

Yes, I think it would be useful to have a widget that returns a datetime.date rather than datetime.datetime object (DatetimeRangePicker already has a disable_time parameter, but still returns a datetime with time = 12:00, which can lead to inconsistencies).
I had to fix a bug in the tests and added the reference notebook. However, I think the DateRangePicker needs a little more work as it shows some of the layout parameters from the DatetimeRangePicker (which I subclassed) that are no longer relevant (enable_seconds, military_time). Any thoughts on how to do this?

@samuelyeewl samuelyeewl reopened this Oct 8, 2021
@jbednar
Copy link
Member

jbednar commented Oct 8, 2021

I haven't looked at the details here, but if you are trying to make a parameter not appear and not be used in a subclass, you can redefine it with the same type but a negative precedence and readonly=True (e.g. x=param.Integer(0, precedence=-1, readonly=True).

@philippjfr
Copy link
Member

I haven't looked at the details here, but if you are trying to make a parameter not appear and not be used in a subclass

That seems like a weird approach honestly, you should instead create a baseclass that has the parameters you do want to be shared and then subclass from that.

@philippjfr
Copy link
Member

Or in this case it might be reasonable to invert the hierarchy and have DatetimeRangePicker inherit from your DateRangePicker.

@jbednar
Copy link
Member

jbednar commented Oct 8, 2021

That seems like a weird approach honestly, you should instead create a baseclass that has the parameters you do want to be shared and then subclass from that.

Good point; that's the right long-term approach. My answer only applies if you are unwilling or unable to do a refactor like that.

@MarcSkovMadsen
Copy link
Collaborator

I need this to to support param.DateRange parameters.

@MarcSkovMadsen
Copy link
Collaborator

MarcSkovMadsen commented Nov 10, 2023

Closes #5844

@philippjfr
Copy link
Member

Superseded by #6027

@philippjfr philippjfr closed this Dec 11, 2023
@philippjfr philippjfr removed this from the next milestone Dec 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants