ICEfaces
  1. ICEfaces
  2. ICE-6722

Allow users to only select future dates or past dates for the selectInputDate component

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.8.2-EE-GA_P02, 2.0.0, 2.0.1
    • Fix Version/s: None
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      All

      Description

      Feature Request: Add an attribute(s) that would cause the selectInputDate to only render or allow dates that are in the future or past of the current date. Currently the only way to restrict these sets of dates is to use a validator and then throw a validation error if a user selects an incorrect date.

      Possible attribute names:
       - disableFutureDates, disablePastDates
       - allowFutureDatesOnly, allowPastDatesOnly

        Activity

        Hide
        Arran Mccullough added a comment -

        Additional requests from customer:

        The described requirement fits our needs allmost. However, to make it a little bit smarter, I would recommend to make it numerically allowing to define the offset of days in the future or in the past.

        eg.
        -futureDaysStart="0" means from today on
        -futureDaysStart="1" means from tomorrow on
        -pastDaysStart="1" means up until yesterday
        ....

        This way one could get a smarter behaviour and the date could be calculated on server side. In our case, if it is before 12:00 lunch time, today must be possible. But after 12:00 dates only from tomorrow on should be selectable. By having the value evaluated by a EL statement it could then calculate on the fly from when on (ur until when) the dates should be enabled.

        As well it would be interesting to limit the time up until when dates could be choosen in the past or the future. By combining all this, there could be defined this way a time window where the user could choose a date.

        eg. the following means to have dates possible from tomorrow up until 10 days from now.
        -futureDaysStart="1"
        -futureDaysEnd="10"

        Show
        Arran Mccullough added a comment - Additional requests from customer: The described requirement fits our needs allmost. However, to make it a little bit smarter, I would recommend to make it numerically allowing to define the offset of days in the future or in the past. eg. -futureDaysStart="0" means from today on -futureDaysStart="1" means from tomorrow on -pastDaysStart="1" means up until yesterday .... This way one could get a smarter behaviour and the date could be calculated on server side. In our case, if it is before 12:00 lunch time, today must be possible. But after 12:00 dates only from tomorrow on should be selectable. By having the value evaluated by a EL statement it could then calculate on the fly from when on (ur until when) the dates should be enabled. As well it would be interesting to limit the time up until when dates could be choosen in the past or the future. By combining all this, there could be defined this way a time window where the user could choose a date. eg. the following means to have dates possible from tomorrow up until 10 days from now. -futureDaysStart="1" -futureDaysEnd="10"
        Hide
        Ken Fyten added a comment - - edited

        I think it is much more flexible to support a min and max date attribute, such as:

        minDate = null or unspecified: No min date (default).
        minDate = 3/01/2011: Cannot select a date earlier than March 1st, 2011.

        maxDate = null or unspecified: No max date (default).
        maxDate = 4/01/2011: Cannot select a date later than April 1st, 2011.

        It would be the application's responsibility to calculate today's date or tomorrow's date, etc. as required and as specified in the description.

        To add even more flexibility, it would be nice to have each attribute support a list of values, creating the possibility of multiple valid ranges in effect at one time. In this scenario, each minDate index value would correspond to a matching maxDate index value (1st with 1st, 2nd with 2nd, etc.).

        For example, to specify that you cannot select a date during July or August of 2011, the following syntax could be used:

        minDate = ", 9/01/2011"
        maxDate = "6/30/2011, "

        Here's an example that only lets you select weekdays for the next 3 weeks:

        minDate = "4/04/2011, 4/11/2011, 4/18/2011"
        maxDate = "4/08/2011, 4/15/2011, 4/22/2011"

        Another approach which might be clearer from an application developer's standpoint would be to simply have dateRangeEnabled and dateRangeDisabled attributes, such as:

        Only select weekdays for next three weeks:
        dateRangeEnabled = "4/04/2011-4/08/2011, 4/11/2011-4/15/2011, 4/18/2011-4/22/2011"

        Disable selection in July or August:
        dateDisabled = "7/01/2011-8/31/2011"

        Show
        Ken Fyten added a comment - - edited I think it is much more flexible to support a min and max date attribute, such as: minDate = null or unspecified: No min date (default). minDate = 3/01/2011: Cannot select a date earlier than March 1st, 2011. maxDate = null or unspecified: No max date (default). maxDate = 4/01/2011: Cannot select a date later than April 1st, 2011. It would be the application's responsibility to calculate today's date or tomorrow's date, etc. as required and as specified in the description. To add even more flexibility, it would be nice to have each attribute support a list of values, creating the possibility of multiple valid ranges in effect at one time. In this scenario, each minDate index value would correspond to a matching maxDate index value (1st with 1st, 2nd with 2nd, etc.). For example, to specify that you cannot select a date during July or August of 2011, the following syntax could be used: minDate = ", 9/01/2011" maxDate = "6/30/2011, " Here's an example that only lets you select weekdays for the next 3 weeks: minDate = "4/04/2011, 4/11/2011, 4/18/2011" maxDate = "4/08/2011, 4/15/2011, 4/22/2011" Another approach which might be clearer from an application developer's standpoint would be to simply have dateRangeEnabled and dateRangeDisabled attributes, such as: Only select weekdays for next three weeks: dateRangeEnabled = "4/04/2011-4/08/2011, 4/11/2011-4/15/2011, 4/18/2011-4/22/2011" Disable selection in July or August: dateDisabled = "7/01/2011-8/31/2011"
        Hide
        Markus Guenther added a comment -

        The ability to limit day ranges would fit our needs even more and would be really a great benefit for such a component Of course in business relation it is often necessary to limit date entries to certain date or time ranges or even certain weekdays.

        So our requirements would be fullfilled with something like that:

        activeDays="Mo;Tue;Wed;Thu;Fri;Sat" allow all weekdays with Saturday
        dateRange="05/04/2011" start from today forever

        or

        activeDays="Mo;Tue;Wed;Thu;Fri" allow all weekdays only
        dateRange="05/04/2011-05/31/2011" from today to end of may

        or

        activeDays=""
        dateRange="01/01/2011-04/04/2011" from begin of year up until yesterday all days

        Note: We here in central europe express dates by day/month/year

        Show
        Markus Guenther added a comment - The ability to limit day ranges would fit our needs even more and would be really a great benefit for such a component Of course in business relation it is often necessary to limit date entries to certain date or time ranges or even certain weekdays. So our requirements would be fullfilled with something like that: activeDays="Mo;Tue;Wed;Thu;Fri;Sat" allow all weekdays with Saturday dateRange="05/04/2011" start from today forever or activeDays="Mo;Tue;Wed;Thu;Fri" allow all weekdays only dateRange="05/04/2011-05/31/2011" from today to end of may or activeDays="" dateRange="01/01/2011-04/04/2011" from begin of year up until yesterday all days Note: We here in central europe express dates by day/month/year
        Hide
        Mark Collette added a comment -

        Some previous brainstorming on the matter: ICE-5477.

        Show
        Mark Collette added a comment - Some previous brainstorming on the matter: ICE-5477 .

          People

          • Assignee:
            Unassigned
            Reporter:
            Arran Mccullough
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: