I'm looking back at this thread now, because I want recurring events to be
handled by SMW in one way or another.
John: I didn't really understand your issue; what's an example of something
that the #ask calendar format can't do?
CNIT: that would work, although I hope there's a way to do it that doesn't
involve creating a new database table; which would be a fairly big step.
My current thinking is that the way to go is to declare a set of new special
properties for recurring events, and that they should be declared directly
within SMW.
-Yaron
On Wed, Mar 25, 2009 at 5:06 AM, CNIT <c...@uniyar.ac.ru> wrote:
> John McClure пишет:
> > *
> > *I am now creating a calendaring mechanism for my wiki that is based
> > on Kenyu's extension but which uses SFs to solicit parameters and
> > content for a <calendar/> element. My [[form:Calendar]] writes the
> > information to SMW properties of the [[calendar:page]]. This page,
> > normally transcluded by another page, contains
> > <includeonly><calendar/></includeonly>. The tag hook extracts the
> > page's properties to build the calendar html. Shared & unshared
> > calendars are distinguished: unshared calendars are <calendar>
> > elements located on non-calendar namespace pages. Non-shared
> > calendars' data is found within the attributes and content of the
> > <calendar> element, meaning the tag hook operates in either mode --
> > upon data located in smw properties, and upon data located in the
> > element itself. *
> > **
> > *My design permits naming [[event:page]] pages to be included in a
> > calendar. The event pages have their own smw properties, such as those
> > indicated below. Additionally, events can be specified for a calendar
> > either in the content of a <calendar> element or in smw attributes of
> > the [[calendar:page]]. A recurring event may only be specified in the
> > context of an [[event:page]], not in the [[calendar:page]], in large
> > part so that the [[event:page]] can have smw properties for
> > non-recurring events developed from 'exploding' (i.e., resolving)
> > recurring event specifications.*
> > **
> > *So my point is? The data for events to be displayed on a calendar can
> > be located in a variety of places -- on an [[event:page]] included in
> > a calendar, on the calendar's own page, and in a calendar element.
> > Meaning there are at least two different smw property models needed,
> > and these should be correlated with the attributes & content of a
> > <calendar> element. Crucially, recurring events' smw properties should
> > correlate as well with iCalendar's data model. *
> > **
> > *OK, but what about {{#ask: |format=calendar}}? I concluded that the
> > widget is a good choice for pure smw data-configs, but a bit
> > inadequate for the shared/hybrid-calendaring tasks I have in mind. The
> > #ask design does NOT contemplate a calendar page/resource, so no way
> > to associate persistent properties with a calendar, meaning a
> > different mechanism -- the predicates on the #ask command -- is
> > necessary to identify which events are to be included on the formatted
> > calendar. *
> > **
> > *Bottom-line is this. The #ask command is used to place wiki pages
> > *which have a date property* as links in a calendar or on a timeline
> > -- while immensely useful, it is not a general calendaring solution
> > now, and arguably not ever. An #ask command that incorporates
> > processing of properties relating to "recurring events" seems a major
> > contortion of its core mission; it suggests poor performance in the
> > end to resolve recurring event data into non-recurring events; and
> > distracts from more targeted and comprehensive solutions for
> > calendaring. *
> > **
> > *Thanks, and comments appreciated!*
> > *John*
> > *
> >
> > -----Original Message-----
> > **
> >
> Every re-occurrence of dates can be simply explained by Ordinal date:
> 1..365 for non-leap year, 1..366 for leap year.
> There are simple formulas for that, freely available.
> The same Ordinal date can be calculated for months (1..31/30/29/28) and
> weeks(1..7), if someone wants to.
>
> If you introduce an additional SQL table, these values can be calculated
> and stored for each [[Type::Date]]
> when the property value is stored by SMW.
> `ordinal_leap`
> `ordinal_nonleap`
> `ordinal_month`
> `ordinal_week`
>
> Then you can simply select an interval of ordinal dates (let's say
> between 100th and 130th day of the year) and it
> will return SMW's internal numerical date values that occured during
> these days.
>
> Just one extra table and no additional properties. I believe that Date
> is a just Date and it's re-occurence
> can be stored as a part of it, just in another table. "Incomplete"
> re-occurent dates just have their Ordinal
> dates without internal numerical value (since year 0).
>
> Then, special kind of #ask can be created to select date properties for
> re-occurring dates.
> I was thinking of such extension, but currently no time to implement.
> Also, I am not sure my
> coding skills are up to MW/SMW standards. Maybe I'll try in the future.
> Dmitriy
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
------------------------------------------------------------------------------
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
