[Tikiwiki-devel] Re: Tikiwiki-devel digest, Vol 1 #1107 - 2 msgs

[Gary G. <gar...@co...>]

> 
>>IMHO
>>I am not sure I understood the concepts and the terminology.
>>With my own work, it will be
>>Each event has a type. I can subscribe to a type of events to receive a mail
>>each time an event of this type is created. The events can be seen in the
>>calendar.
>>Actually, I don't understand why there are a calendar description and a
>>"event newsletter" . It is likely to be the same?
>>Why using newsletters and not the watch function?
> 
> 
> newsletters could be sent to people subscribed to the event, for example 
> in my case it will be a booking form, or a newsletter to change the 
> location of the event.
> 

When I wrote this, I envisioned each event having its own subscriber 
list. A notice (newsletter) could be sent as a reminder or a summary of 
the event. Or to change some important attribute of the event (speaker, 
location)

Or to post an event before the actual date is decided. So it might not 
have a calendar connection.

> 
>>I don't understand also the "e"(=event registration) in the calendar. Do you
>>register to this specific event or the class of events?
>>

You register for the specific event.

>>It will be very easy to do a user watch on a calendar category... Each time
>>a new event of this category is created a mail is sent to the watchers.
> 
> 
> Not powerful enough for me.
> 
> 
>>Damian has some ideas to extend "event article". It is true that when you
>>want to create an event... you will like to present it in your home page
>>.... So perhaps we can connect both. It will give some more sense to the
>>event article and connect together object with date.
>>When you create an event article, it creates an event in the calendar that
>>links to the article... and the user watches do the rest of the job
> 
> 
> Mine needs to be ready by Fri 5th, but Im planning on using the new mods 
> system to distribute it.
> 

I liked Damians idea of an Article of type Event as opposed to what I 
did. I guess I rushed and didn't see this as an alternative.

So the question is... Is the code really thought thru enough to include 
in the release given the disagreement on functionality. I suspect that 
discarding it might be the right answer.

-- 

gar...@co...