Opened 6 years ago

Closed 3 years ago

#16665 closed enhancement (patchwelcome)

Enhance dojox.Calendar to support retreiving only the visible events as needed

Reported by: back40 Owned by: dg
Priority: undecided Milestone: 1.13
Component: Dojox Version: 1.8.3
Keywords: Cc:
Blocked By: Blocking:

Description

First, I love the new dojox.Calendar. It's easily the best looking and most configurable of any javascript Calender/Schedule? component I've come across. The only thing I don't like about it and that doesn't make sense to me is that it when you first set the store, it retrieves *all* events from the store and from then on, just uses an array to determine which events are visible. If this is in an office environment where it could be used over a period of years, that can end up with a lot of events. Even if it's not a performance issue or memory issue to get all events all the time, something about it just doesn't feel write, so I think there ought to be a good way to make it work either way (query all or only on demand).

I'm a total dojo n00b so feel free to correct whatever I write here. I think it would make sense to alter StoreMixin?._computeVisbleItems to retrieve data from the store instead of assuming a full in memory array of items. At first it seems like store.query is the right approach, but I think that's insufficient. The problem, as I see it, is that something like store.query({startDate: xyz, endDate: xyz}) isn't enough. That doesn't convey the intent that you really want to query for events that start between start and end date, not find events with that matching start and end date. So for a JsonRest? store, the rest api might assume this sort of query, but for a Memory store, it would have to interpret that query differently than other queries. I'd like a solution that works the same with any store with the least amount of compromises.

So my proposal is to change StoreMixin? so that instead of a Store, it takes something like dojox.calendar.StoreAdapter?. StoreAdapter? would provide a new method, perhaps called queryEvents(startDate, endDate) and would do the right thing for the underlying Store. So, for example, a JsonStoreAdapter? would implement queryEvents by just executing a rest get like /myservice/events?startDate=123&endDate=456. But for a MemoryStoreAdapter?, it could simply filter the in memory array of events with isOverlapping like the current StoreMixin?._computeVisibleEvents does. The nice thing is then it would be easy to replace or extend these adapters depending on your need. Maybe I'd like my RestStoreAdapter? to cache a month of events to make switching faster, or if you like how it works now for speed, you could simply have a RestStoreAdapter? that still queries all events and then queryEvents simply uses a full in memory array. But at least it would be easy to write your own adapter to work however you'd like. And StoreMixin? just doesn't seem the right place to be doing something like isOverlapping because that should really be implemented differently for different stores (or at least have the option to do so).

This is what I've been trying to make work locally here and it turns out that it's a very minor change (so far) to StoreMixin? to make this work -- essentially just getting rid of the logic in setStore and the isOverlapping part in _computeVisibleItems and having that call queryEvents instead, although I haven't worked out handling Observable yet. The fact that it's been easy to change so far is really a testament to how well this component has been designed and thought-out.

Anyway, that's my idea. Does it make sense? Seem like something that would be worthwhile or am I thinking about this all wrong?

thanks.

Change History (5)

comment:1 Changed 6 years ago by cjolif

Owner: changed from dante to dg
Status: newassigned

comment:2 Changed 6 years ago by dg

Hi back40,

I agree that the data management of a calendar/schedule widget is not like a list because of start/end are dates and not indices.

There's definitively room for improvement in that area in a future version if time permits.

Concerning the form, it still needs to be investigated, but all the data management should be in a store. A possibility would be to create a dedicated store query engine.

Again, when time permits, we'll try to address this need.

Thanks,

comment:3 Changed 6 years ago by bill

Component: DojoX WidgetsDojox

comment:5 Changed 3 years ago by dylan

Milestone: tbd1.12
Resolution: patchwelcome
Status: assignedclosed

Given that no one has shown interest in creating a patch in the past 2+ years, I'm closing this as patchwelcome.

Note: See TracTickets for help on using tickets.