[MKDoc-dev] Proposed event/calendar functionality
Sam Tregar
sam at tregar.com
Wed Oct 13 18:22:33 BST 2004
On Wed, 13 Oct 2004, Bruno Postle wrote:
> In addition to these existing ad-hoc types, we want to be able to make an
> MKDoc document an Event (in time) and later-on, a Place (in space).
I think I understand what you mean by an Event, but what do you mean
by a Place? Or is this future work that doesn't require consideration
now?
> Elsewhere a calendar can be displayed, this will be customised to
> show only productions in the future matching a visitors audience
> preferences:
Does a calendar component already exist or what that be part of this
development too?
> Rather than trying to stuff this information into the document
> attributes, the plan is to create a new 'component type' that
> represents a 'time range' - This solves the potential problem of
> repeating-events requiring complex configuration rules - Under this
> model a repeating event simply has multiple 'time range' components.
Does the editor have to manually add each instance of a repeating
range? For example, an event might occur every other Wednesday from
4pm to 5pm.
> This will be stored in the document Body in the same way as existing
> components, though events need to be search-able, so a new SQL table is
> required:
Will the data be replicated, i.e. stored in both the Body and in the
Component_TimeRange table for searching? Or will the data be stored
in the Component_TimeRange and merely referenced from Body?
> Component_TimeRange
> --------------------
> ID Char
> Date_Start TimeDate
> Date_Start_TZ Char
> Date_Stop TimeDate
> Date_Stop_TZ Char
> Title Char
>
> (I realise that this is missing the Document_ID, very important)
Can you elaborate on why Document_ID is missing and why this is
important? It seems to me that the relevent Component_TimeRange.IDs
could be stored in the Body and then Component_TimeRange.Document_ID
wouldn't be needed.
Thanks,
-sam
More information about the MKDoc-dev
mailing list