[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-09-02/Enterprise Deployment (built 2024-09-02)

Hello, while I'm testing it, a question comes to mind: could the Calendar also support refreshData() and/or invalidateCache() methods?

[Isomorphic]

hi Claudio,

We've addressed the fetch issues - databound Calendar's basically require all the event-records for the current filter to be client-side at render-time - we don't create or render all the event canvases up-front, of course (we do that as you scroll around) but we do need the data to be available to facilitate features like overlapping/space-sharing.

This means that Calendar should always have been using dataFetchMode: "basic", but wasn't setting a value in code, so was defaulting to "paged". We've made that change so you'll no longer see start/endRow numbers or multiple fetches.

We've also made the rangeCriteria official and switched it on by default - new public doc for Calendar.includeRangeCriteria, default true (it's on CalendarView as well, but still undoc'd there for the moment).

Finally, on the [N/A] in the Raw Response tab - we'll take a look and get back to you.

[Isomorphic]

hi guys,

Blama - thanks, we've fixed so that the rangeCriteria dates are both datetimes where expected and that should address the example you described

Claudio - thanks for the followup - we're considering whether we need/the best way to deal with real-paging (of large result-sets returned as a result of rangeCriteria) and will update here in the coming days. We'll also get to the bottom of why the secondary automatic fetch you described was apparently not limited by the rangeCriteria.

[claudiobosticco]

Thanks for the update.

After thinking about it, I can imagine use cases (quite different from mine) where you might have a large number of events. I'm not sure what the desired behavior would be in that scenario, but if I try to create 1000 events in the sample above:

var now = new Date().getTime();
var eventData = [];
for (var i = 0; i < 1000; i++) {
    eventData.add({
        eventId: i, name: "event " + i, description: "event description " + i,
        startDate: new Date(now + i * 1000 * 60 * 35),
        endDate: new Date(30 * 60 * 1000 + now + i * 1000 * 60 * 35)
    })
}

I immediately notice two fetches: one for the 0-75 range and another for the 75-1000 range (*). Even though there are just a little over 80 events displayed in the current week, and to see the others, you have to switch to month view and then navigate to September.

(*) By the way, in the raw response tab for the 75-1000 request, I see [N/A]. Is this a new setting that prevents large responses from loading, or is there an issue with the developer console?

[Isomorphic]

Thanks guys - we'll revisit this functionality, the range values and the fetch-size issue, and get things working more cleanly for tomorrow's builds. We'll update when the updates land.

[claudiobosticco]

Claudio - yes, the requests are still paginated, as requested - so you're going to see paging numbers. It's just paging withing the range of dates that were specified.

Hello, I'm not sure I'm understanding. If in the selected view, for the visible range, there are 80 events, I'll see just 75 of them? I can imagine that, in the day and week views, scrolling could trigger a fetch, but I see startRow and endRow even in the month view without scrolling :confused:

[claudiobosticco]

just go to the sample (SNAPSHOT_v13.1d_2024-08-29), enable includeRangeCriteria by putting your line from #13 in the code, start the sample and switch to month view.

I can confirm this, also in my application.

[Blama]

Hi Isomorphic,

just go to the sample (SNAPSHOT_v13.1d_2024-08-29), enable includeRangeCriteria by putting your line from #13 in the code, start the sample and switch to month view.

Best regards
Blama

[Isomorphic]

Claudio - yes, the requests are still paginated, as requested - so you're going to see paging numbers. It's just paging withing the range of dates that were specified.

Blama - we're not sure we follow your comments. If the start and end dates really produce one a datetime and the other a date, that would be a problem. But we aren't seeing that - so can you show the sample code that resulted in those two fields being given different accuracy??

[Blama]

Hi Isomorphic,

very cool. I had a look at the criteria and think they might be too restrictive at the interval ends.
First I noticed that some criteria come with time, some without.

criteria:[
            {
                fieldName:"startDate",
                operator:"lessThan",
                value:"2021-07-31T21:59:59.999"
            },
            {
                fieldName:"endDate",
                operator:"greaterThan",
                value:"2021-06-27"
            }
        ]

I'd expect a time for the start as well (perhaps not important, but most likely yes with time zones) and the operators lessOrEqual and greaterOrEqual (normally only on one side, but as you already deduct the millisecond, closed intervals on both sides needed).
Try setting disableWeekends:false here (and your code from #13, SNAPSHOT_v13.1d_2024-08-29) creating an event for 2021-06-27 and 2021-06-28 in month view of June.
Even though both dates are also in the July view, only the event for 2021-06-28 is displayed in July view. I'd expect also the event for 2021-06-27 to be displayed.

Thank you & Best regards
Blama

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-08-29/Enterprise Deployment (built 2024-08-29)

Hello, from a quick test it seems to work, very nice!

But I noticed that in the request there's still startRow:0, endRow:75, I think that they must be removed. I don't have more than 75 events in a month, but the "old" pagination seem to be still there.

[Isomorphic]

We've made this available in 13.1, but it isn't yet public - there are numerous ways for this to work and we haven't fully settled on one yet.

But if you want to try it today, you can do that with this code before creating your calendar

isc.CalendarView.addProperties({ includeRangeCriteria: true })

As-is, your Calendar will fetch whenever the range changes to a different range. Specifically, it will check range-criteria in all views every time you navigate; if the new range is entirely inside the previous range, no fetch occurs and the UI is updated from the already-fetched data - otherwise, fetching occurs via filterData(). So, if you show the Week view, it will fetch with a range of that week - if you then change to the day view, it will not fetch, until you navigate outside of the initial week-range, and then it will fetch for a single day - if, at that point, you change to another view, it will re-load for that less restricive range. Similarly, if you show the Month view, neither Day nor Week views will fetch until you navigate outside of the current Month

[Isomorphic]

We're looking at this right now and will aim to have it fixed for tomorrow's builds.

[claudiobosticco]

Hello, any news on this issue? I see it's still using startRow and endRow in the latest 13.1

[Isomorphic]

Apologies for the silence on this report - we'll get to it this week and update here.