This project is read-only.

Tokens and Query Filters


The Schedule part should have its own tokens and query filters implementation.

Token would allow to display the range of dates in a friendly way.
Ex : {Content.Parts.MyContentType.MySchedule.Text} =>
'from startDate at startHour to endDate at endHour'
Or if same day :
'on startDate from startHour until endHour'

Separated StartDate and EndDate tokens would be useful too.

Query filters would be quite similar to Date filters but would allow to specify you want to display the contents where dateStart and/or dateEnd is greaterThan a certain date.
Ex : DateStart > Now to avoid to display past dates

In don't know. if you can do it easily, depending on how you made the recurrence property.

For these needs (and for localization and timezone), StartDate and EndDate should be stored as date and not as string.

At last, it could may be help to create some Workflows activities triggered at the start or at the end or at each occurrence (but it might be tricky).
I guess it should have some events : Started, Occurred, Finished.


flew2bits wrote Nov 22, 2013 at 2:27 PM

The tricky part with a lot of this is how schedules are stored. The "startDate" of a schedule is the very first date that a recurrence can start. The ScheduleService provides a method to get all occurrences of a scheduled item between a start and end date, and that includes the actual start and end datetimes for the particular instance of the schedule.

I've been thinking about a way to provide some means to add details to a particular instance of a scheduled event, but I haven't resolved it entirely. My thoughts at this time are to extend the routing so that if you add a date onto the end of a content item link that and it meets the requirements of the schedule, then it can display details specific to that date. Perhaps Lists will be the way to go when those get reincorporated.

As strange as it may seem, I actually think the workflow activities might be the easiest to implement at this time.