Calendar DataBound Pagination

[aderosso]

Does the Calendar widget support date based pagination natively?

I saw this forum post: https://forums.smartclient.com/forum...and-pagination I just wanted to double check that this was still the case before starting making changes to use the DateChangedEvent.

[Isomorphic]

hi aderosso,

Current Calendar code will request all data for the visible date-range, and request new data when the visible date range changes, but doesn't perform row-range pagination on scroll, for example, in the same way as ListGrids.

[aderosso]

Is there something else I would need to do other than this:

        final Calendar calendar = new Calendar();
        calendar.setDataSource(DSConst.CalendarEventSQL.DATASOURCE);
        calendar.setAutoFetchData(true);
        calendar.setStartDateField(DSConst.CalendarEventSQL.START_DATE);
        calendar.setEndDateField(DSConst.CalendarEventSQL.END_DATE);
        final AdvancedCriteria criteria = new AdvancedCriteria(OperatorId.OR,
                new Criterion[] { new Criterion(DSConst.CalendarEventSQL.OWNER_ID, OperatorId.EQUALS, 1L),
                        new Criterion(DSConst.CalendarEventSQL.CREATOR_ID, OperatorId.EQUALS, 1L) });
        calendar.setImplicitCriteria(criteria);
        calendar.draw();

I'm setting the start and end fields, but it's still just fetching based on the criteria and rows 0-75.

[Isomorphic]

We're not sure what you mean by "based on the criteria".

As explained above, the expectation is that the Calendar fetches the data based on the visible date range, but does not use row-number-based pagination: all calendar entries for the visible date range will be fetched.

So you would expect to see some date-related criteria automatically generated and sent for you. Please tell us whether you are seeing that.

If you are not, you should:

1) see whether you actually have the start and end date fields declared correctly, and as type="datetime" fields (e.g. this would not be expected to work if those fields were not declared, declared to be the wrong type (eg "integer") or were not visible to the current user)

2) try removing your use of implictCriteria. You're hoping to use inherited functionality here, we'll have to check whether it's actually supported in this case. If you find it's creating a problem, there are many other ways to introduce those criteria into the request, such as DataSource.transformRequest(). Here, it looks like the criteria involved may actually be needed for security reasons, in which case you should be introducing those criteria on the server side (e.g. in DMI logic) and not in client-side code.

[aderosso]

I removed the criteria completely. Now it's just this:

final Calendar calendar = new Calendar();
calendar.setDataSource(DSConst.CalendarEventSQL.DATASOURCE);
calendar.setAutoFetchData(true);
calendar.setStartDateField(DSConst.CalendarEventSQL.START_DATE);
calendar.setEndDateField(DSConst.CalendarEventSQL.END_DATE);
calendar.draw();

The fields are defined as:

<DataSource ID="CalendarEventSQL"
            serverType="sql"
            tableName="calendar_event">
    <fields>
        <field name="calendar_event_id" type="sequence" primaryKey="true" hidden="true"/>
        <field name="name" type="text" required="true" length="40"/>
        <field name="description" type="text" length="100"/>
        <field name="notes" type="text" length="100"/>
        <field name="creator_id" type="integer" hidden="true" foreignKey="UserSQL.userId"/>
        <field name="owner_id" type="integer" hidden="true" foreignKey="UserSQL.userId"/>
        <field name="project_id" type="integer" foreignKey="ProjectSQL.projectId" hidden="true" joinType="outer"/>
        <field name="start_date" type="datetime" required="true"/>
        <field name="end_date" type="datetime" required="true"/>
        <field name="status_id" type="integer" foreignKey="CodeSQL.code_id" hidden="true" joinType="outer"/>
        <field name="statusValue" type="text" canEdit="false" includeFrom="CodeSQL.code" includeVia="status_id"/>
        <field name="created_by" type="creator"/>
        <field name="created_time" type="creatorTimestamp"/>
        <field name="modified_by" type="modifier"/>
        <field name="modified_time" type="modifierTimestamp"/>
        <field name="canEdit" type="boolean" hidden="true" customSQL="true"/>
    </fields>
</DataSource>

The request in this case is still just fetching rows 0-75:

{
    dataSource:"CalendarEventSQL",
    operationType:"fetch",
    componentId:"isc_Calendar_0",
    data:{
    },
    startRow:0,
    endRow:75,
    textMatchStyle:"exact",
    resultSet:[ResultSet ID:isc_ResultSet_0 (dataSource: CalendarEventSQL, created by: isc_Calendar_0)],
    callback:{
        caller:[ResultSet ID:isc_ResultSet_0 (dataSource: CalendarEventSQL, created by: isc_Calendar_0)],
        methodName:"fetchRemoteDataReply"
    },
    willHandleError:true,
    showPrompt:true,
    prompt:"Finding Records that match your criteria...",
    oldValues:{
    },
    requestId:"CalendarEventSQL$6270",
    internalClientContext:{
        requestIndex:1
    },
    fallbackToEval:false,
    bypassCache:true,
    dataProtocol:"getParams"
}

[Blama]

Hi Isomorphic,

I can see the same behaviour with a 0-75 paginated fetch in this unchanged sample (v13.0p_2024-02-21, FF 122, Win10).

Best regards
Blama

[Isomorphic]

Apologies for the delay in responding here - you're both correct, date-range criteria is not being included by default, except in Timelines.

We're looking into it and will update here as soon as we have it fixed.

[aderosso]

Is there any update on this issue?

[Isomorphic]

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

[claudiobosticco]

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

[Isomorphic]

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

[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

[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.

[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

[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??