Question about workdays in Calendar

[martintaal]

Hi, we have a problem handling workdays. We delegate all the logic about workdays in dateIsWorkday function because we need to handle holidays and different availability times depending on the date (different season timetable).


We see that if we set a workdayStart, the viewport is moved to that row, that is ok. The problem is our "workdayStart" is different depending on the day (delegated in dateIsWorkday function).

We would need one of the following solutions (in preference order):
1) The viewport is moved to a time based on dateIsWorkday (the first available hour)
2) A new function "scrollToTime", with action similar to "scrollToWorkday" boolean, but with the capability to pass a fixed time

P.S: Currently we have
showWorkday: true,
workdayStart: '00:00',
workdayEnd: '23:59'
We don't want to change workdayStart because if we do that, we have with no-workday style all cells from 00:00 to the fixed set date, and we don't want this (again, we delegate in dateIsWorkday)

Thanks and regards

[martintaal]

bumped up...

gr. Martin

[Isomorphic]

We're looking at this and will update the thread when we have more information.

[Isomorphic]

Looking into it, we decided to go ahead and add this feature for you.
We have now added support for customizable, date specific workday hours via overrideable, public methods "getWorkdayStart()" / "getWorkdayEnd()".

This change will show up in the next nightly build (March 21) on the 9.0d and 8.3p branches

Regards
Isomorphic Software

[martintaal]

Thank you very much, but I think now the behavior is worst than before, I explain why: Before the change, once I load the calendar, I be in the first workday hour (let's supose 09:00). If I scroll down (let's supose to 14:00), and I move to the next day, now the scroll is again in 09:00. Before the changeset it remained in 09:00

I think the previous behavior was better, since maybe I want to see a free gap between 14:00 and 15:00, and the logic behavior is scroll to this time, and if it is busy, move to the next day (and view the same time lapse, instead of manually scroll again).

If you want to maintain both behaviors, maybe a new attribute: scrollToWorkdayWhenDayOrWeekChanges would be nice (although particularly we need the previous behavior).


Now, about the point that originaly I asked, with getWorkdayStart and getWorkdayEnd is not solved, since we relegate all the workday logic to dateIsWorkday function.

We have something like:

isc.Calendar.create({
  ID: "eventCalendar", 
  scrollToWorkday: true,
  showWorkday: true,
  workdayStart: '00:00',
  workdayEnd: '23:59',
  dateIsWorkday: function (date) {
//our custom code
  },
  data: eventData
});

As you can see, initially we say that all the day (from 00:00 to 23:59) is workday because we want to use showWorkday (but set it using dateIsWorkday).
The problem is with "scrollToWorkday": we need to scroll to a particular time when the calendar is loaded

With the following solution I think we would be done:
Add a function like "scrollToTime(time)" that could be called in the initWidget or so, so we put the scroll wherever we want (independently of the workdayStart)

I think for you it would be as easy of create it, that basically it would be a copy of the current "scrollToWorkdayStart", but the time as a parameter instead of the fixed workdayStart. Then the "scrollToWorkdayStart" could just call the new "scrollToTime" with the workdayStart as a parameter.


Thank you again.

Regards.

[Isomorphic]

Your test code doesn't actually *use* the new feature.

You need to override getWorkdayStart() and getWorkdayEnd() to return values appropriate to the date passed into them. By default, those methods will return calendar.workdayStart and calendar.workdayEnd respectively.

In that way, the Day View will scroll to the beginning of whatever getWorkdayStart() returns for the current day and, in the week view, it will scroll to the earliest time returned for any of the days.

Please try this out - if it doesn't do what you need, please be very precise about what you *do* need.

[martintaal]

Thanks for the reply:

1) You have added this code to "setChosenDate" function:

    } else {
        var view = this.getSelectedView();
        if (this.scrollToWorkday && view.scrollToWorkdayStart) {
            view.scrollToWorkdayStart();
        }
    }

As I said in my previous post, this new behavior is an undesired effect, since now (with this change), each time I change the date, the scroll is moved (to the workdayStart), and we only want the scroll position when the calendar loads (as it was before), and no each time the day changes (we want to preserve the new scroll position where the user has scrolled even after a day change). Maybe a new parameter to has this particular behavior or not could be nice (we will set it to 'false' because we don't want it)

2) We delegate all the workday logic to dateIsWorkday function. Why this new getWorkdayStart() function doesn't work for us? Let imagine the following case:

We have these working hours (returned by dateIsWorkday) for a PARTICULAR day:

00:00 -> 06:00 : NO Working hours
06:00 -> 14:00 : Working hours
14:00 -> 16:00 : NO Working hours
16:00 -> 19:00 : Working hours
19:00 -> 23:59 : NO Working hours

and we want when the calendar loads, the scroll goes to 09:00

Using your new getWorkdayStart() function to put the scroll when the calendar loads to 09:00 will also block (set as NO Working hours) 06:00 -> 09:00 (even if dateIsWorkday doesn't block it), so it doesn't fit to us. So, we need a function to scroll the Calendar, independently of the workdayStart or getWorkdayStart() functions

I hope with this explanation everything be more clear.

Thank you very much

[Isomorphic]

That's correct behaviour for the feature - when the day changes, the start of the workday is re-evaluated and, if you've requested that we scroll to the start of the workday by setting scrollToWorkday, then that will happen.

The problem here is that you don't actually *want* to scroll to the start of the workday - you want to scroll to an arbitrary time, which is *after* the start of the workday, in your sample. So you just shouldn't be using scrollToWorkday at all.

We'll add a scrollToTime()-like API for tomorrow's build and, once you have that, you should just switch scrollToWorkday off.