[EventCalendar] Event Calendar - Recuring Event

Pat Erler perler at gmail.com
Fri Oct 17 19:03:05 UTC 2008


On Fri, 17 Oct 2008 20:46:55 +0200, <firetree_ec3 at spamex.com> wrote:

> Alex is right. It really needs to be one event.
>
> The issue comes when you need to put in exceptions (This week's meeting  
> will be on Thursday, instead of Wednesday). In cases like this, you need  
> to make sure that the event that would normally show is hidden, and the  
> exception is displayed. The exception needs to be tied to the original,  
> but as to HOW tied; well, that ain't such a simple question. Should the  
> only difference be the time and date? Suppose they are also meeting in a  
> different location?
it wouldn't matter with my proposed model as one event-series as a group  
of posts. change whatever you want, the code to handle (hide/view) a post  
wouldn't need to be changed, all implementation work would happen in the  
editor.

for me, the changes would lead to a kind of template-editor for EC posts.  
group them, they start identcal (in content and time) and if you later  
decide to change one event (in content or time), do so, the view/hide  
functions of EC take care of separate posts right now, they will do in the  
future to..

PAT


>
> The vCalendar (iCal) format has a gazillion different fields to describe  
> repeats and exceptions. In the work I'm doing, I had about 2/3 of them  
> accounted for, but I still have some more to go.
>
> catchall account
>
> On Oct 17, 2008, at 2:35 PM, Alex Tingle wrote:
>
>> * Replies will be sent through Spamex to eventcalendar at firetree.net
>> * For additional info click -> http://www.spamex.com/i/?v=17832931
>>
>> All calendaring systems I know of consider recurring events to be ONE  
>> event, that recurs. iCalendar has one entry with a single UID.
>>
>> If/when Event Calendar supports recurring events, each series will be a  
>> single event in a single post. The database field already exists - if  
>> someone wants to put the work into the code to process it.
>>
>> -Alex
>>
>> --
>>
>> On 17 Oct 2008, at 19:17, Pat Erler wrote:
>>
>>> i'm not sure if they'll hate it, most people will not be affected by  
>>> this change anyway and those who need recurring events will be happy  
>>> if at least one of those models is implemented.
>>>
>>> i think, the one i prefer is easier to implement, all it seems to need  
>>> is a table in the db which keeps track of posts that belong together  
>>> and a query to this table whenever you change a post to decide if  
>>> several other's need to be changed as well..
>>>
>>> PAT
>>>
>>>
>>>
>>> On Fri, 17 Oct 2008 20:05:08 +0200, Rick Boatright  
>>> <rboatright at gmail.com> wrote:
>>>
>>>> As I said Pat,  it's  an issue of philosophy.
>>>>
>>>> It seems _unlikely_ that EC3 will support both models (although I  
>>>> suppose
>>>> that's possible. )
>>>>
>>>> The point is, some people will hate EITHER model.
>>>>
>>>> Rick
>>>>
>>>>
>>>> On Fri, Oct 17, 2008 at 12:53 PM, Pat Erler <perler at gmail.com> wrote:
>>>>
>>>>> hi,
>>>>>
>>>>> On Fri, 17 Oct 2008 19:25:46 +0200, Rick Boatright  
>>>>> <rboatright at gmail.com>
>>>>> wrote:
>>>>>
>>>>> There is a MAJOR  ---  utterly non-trivial problem here, and at the  
>>>>> core
>>>>>> it
>>>>>> is philosophical.
>>>>>>
>>>>>> Remember that in EC3, calendar entries are WORD PERFECT POSTS.
>>>>>>
>>>>>> So, when creating a recurring event, which of the following do you  
>>>>>> do?
>>>>>>
>>>>>> 1) Add multiple SCHEDULE items to a SINGLE POST            or
>>>>>> 2) Add multiple POSTS to the blog?
>>>>>>
>>>>>> 1) has the disadvantage you cite below:  The schedule gets messy  
>>>>>> (to say
>>>>>> the
>>>>>> least.  Consider a weekly meeting for a year.)
>>>>>>
>>>>>> 2) has the disadvantage of cluttering up the post database,making  
>>>>>> the
>>>>>> system
>>>>>> mess with that, and being a pain to edit and etc.
>>>>>>
>>>>> nope, this is exactly what a lot of people want. when you have a  
>>>>> meeting or
>>>>> a broadcast every 2 weeks, you want to have a post for each of them,  
>>>>> no
>>>>> clutter here. just put them in a group to remove them all at once  
>>>>> (or make
>>>>> changes to them) and you are done (besie the sideffects i forget  
>>>>> here ;) )
>>>>>
>>>>> PAT
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Blog: http://wpcal.firetree.net/
>>>>> EventCalendar at firetree.net mailing list
>>>>> Unsubscribe: http://penguin.firetree.net/eventcalendar
>>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Blog: http://wpcal.firetree.net/
>>> EventCalendar at firetree.net mailing list
>>> Unsubscribe: http://penguin.firetree.net/eventcalendar
>>
>>
>> _______________________________________________
>> Blog: http://wpcal.firetree.net/
>> EventCalendar at firetree.net mailing list
>> Unsubscribe: http://penguin.firetree.net/eventcalendar
>
>
> _______________________________________________
> Blog: http://wpcal.firetree.net/
> EventCalendar at firetree.net mailing list
> Unsubscribe: http://penguin.firetree.net/eventcalendar





More information about the EventCalendar mailing list