Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    9.1d Calendar: best way to filter events

    Hi,
    I am using the 9.1d calendar (build 22th of october). I am filtering the events and lanes in the calendar using some combos. Currently I filter the events myself and then do setData on the calendar.

    However, I noticed that there is a _getEventsInRange : function (start, end, grid) function. It would be great if there would be an override point to be able to return if an event should be rendered or not. Like: isValidEvent(event) or isEnabledEvent(event), this function could be called from the getEventsInRange I think.

    Or is there another efficient way to filter events in the calendar (instead of doing setdata with a new set)?

    gr. Martin

    #2
    What inefficiency are you trying to avoid? Fetching data from the server? That would require a whole load-on-demand subsystem and couldn't be done externally to the Calendar.

    Comment


      #3
      Hi,
      I keep a separate copy of my events read from the server (next to the one in the calendar). When a filter action happens I go through my copy of the events (after duplicating it) and remove the ones which should not be displayed. Then I call setData on the calendar with the filtered data and I call setLanes (as also the lanes get filtered). The setLanes refreshes the events, this refresh (in the Isomorphic) also walks through the events to see which ones to display in the current day/week.

      I prefer to let the complete set of data being managed by the calendar, but that's only possible (I think) if I can hide events if they are not part of the filter.

      Or another approach is to individually remove/add events from the calendar. What is your opinion is this faster than doing one batch setData and refresh?

      Or if there is another way to implement event filtering in a better way (then calling setData and refresh) then I am interested to hear about it!

      gr. Martin

      Comment


        #4
        With the calendar as it stands, setData() with the new set of records is the right approach.

        Having built-in support for filtering, including optional lane elimination, would be a valid Feature Sponsorship if you want to replace what you have. This could also involve adding support for load on demand.

        As far as your filtering code, hopefully you are already using some combination of ResultSet and/or direct calls to DataSource.applyFilter(), as this will do all the "heavy lifting" for you.

        Comment


          #5
          Just a quick followup in this vein - as of today's build, we now generate fetch criteria for data-bound calendars and timelines, and we pass it on, to a method you can override to adjust the criteria (adjustCriteria() is the current name, but this is undoc'd functionality, so that name may change).

          By default, a databound view will now only fetch events that appear in the current date-range (the range you can get to with the scrollbar). When the range changes (programatically or via the next/previous buttons), criteria is rebuilt and used for the fetch.

          This ought to help in your filtering endeavours - make your calendar data-bound and add an adjustCriteria() override that adds your externally collected criteria to the date-criteria passed in. Then just calling setLanes() should result in your adjustCriteria() override being called before the fetch goes to the server.
          Last edited by Isomorphic; 11 Nov 2013, 21:56.

          Comment


            #6
            We jumped the gun a bit in letting you know about this feature. It's actually *not* going to make it into 9.1, so you can't make use of it for the moment.

            Comment


              #7
              Hi,
              Okay, I don't use the datasource at the moment, I call setData with pre-filtered events still.

              The main feature is renderEventsOnDemand (other thread), so performance improvement, easier filtering is a nice to have.

              Thanks.

              gr. Martin

              Comment

              Working...
              X