Re: UNL Event Publisher

[Brett Bieber]

Hey Nathan,

I've copied this to the general discussion mailing list, so we keep
others in the loop. Some responses below.

On Tue, Jun 1, 2010 at 1:01 PM, Nathan Kern <nk_ange...@hotmail.com> wrote:
> Dear Mr. Bieber,
>
> I’m a student worker at Union College, and one of my summer projects is to
> try to implement either repeating events or iCal import in the UNL Event
> Publisher. I was curious what work, if any, has been done on this
> previously, and which you would recommend focusing on.

Well, iCal import would be parsing vCards, and vCards have repeating
event details in them. Therefore it might be best to work on recurring
event support before tackling the vcard import?

I haven't had much time to look into either, but we do plan on making
some improvements to the events system this month. In particular I'm
interested in adding CalDAV support (which also would require vCard
parsing capabilities — I've been looking at this library from a fellow
developer, Evert Pot: http://code.google.com/p/sabredav/).

All of these sound like great additions. Please keep us in the loop if
you decide to try and tackle any of them.

--
Brett Bieber
University of Nebraska-Lincoln

[Nathan Kern]

Thanks. I think I will start working on recurring events soon, then.

Since this is the first open-source project I've had to work on, do
you happen to know of any in-depth documentation? I apologize if I'm
causing you to go out of your way. It's my first year actually working
as a programmer.

Nathan Kern

[Nathan Kern]

Up until now I've been trying to implement recurring events by editing
UNL/UCBCN/Eventdatetime.php. Now I'm wondering if I shouldn't just
create a new class and put it in Eventrecurrence.php (or similar). Is
there something I don't know that I should be considering?

[Brett Bieber]

Ideally the recurrence should refer to a single eventdatetime
instance. The recurrence would have its own entries that specify the
recurrence sequence for the specific date & time. I would begin by
building a model/schema for the table that will store the recurrence
information. Once you have the model for the how the data should be
stored, you'll know how to modify queries for the backend to get the
applicable dates for an event. I would think of it as the
eventdatetime record as the single, master date instance of an event,
the recurrence table should only specify the recurrence rule and just
reference the eventdatetime_id as a foreign key.

Hopefully that gives you some ideas. :-)

Feel free to shoot ideas back to the list and ask questions if you hit
any roadblocks.

[Nathan Kern]

Okay. I think I've got all the functionality down, at least on my
computer. Below is the list of files I added/modified.

~/UNL/UNL_UCBCN$ svn status
M UNL_UCBCN_db.xml
A UNL/UCBCN/Recurringdates.php
M UNL/UCBCN/Eventdatetime.php
M UNL/UCBCN/EventInstance.php
M UNL/UCBCN/EventListing.php

~/UNL/UNL_UCBCN_Frontend$ svn status
M UNL/UCBCN/Frontend/MonthWidget.php
M UNL/UCBCN/Frontend/Day.php
M UNL/UCBCN/Frontend/Month.php
M UNL/UCBCN/Frontend.php

~/UNL/UNL_UCBCN_Manager$ svn status
M UNL/UCBCN/Manager/EventForm.php
M templates/default/manager.js
M templates/vanilla/manager.js

I get a feeling that there's some more files that I need to edit,
particularly for setting up the database, but I don't want to screw
anything up, so could you let me know what else I am missing?

Thanks.

Nathan Kern

[Brett Bieber]

Hi Nathan,

Do you have a list of all the tables & fields added/modified in the database?

This file describes the entire database for the system:
http://code.google.com/p/unl-event-publisher/source/browse/UNL_UCBCN/trunk/UNL_UCBCN_db.xml

That file allows us to automatically upgrade the database of any Event
Publisher installation, so the changes should go in there.

> --
> You received this message because you are subscribed to the Google Groups "UNL Event Publisher" group.
> To post to this group, send email to unl-event...@googlegroups.com.
> To unsubscribe from this group, send email to unl-event-publi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/unl-event-publisher?hl=en.

[Nathan Kern]

I think I've taken care of that .xml file. I just wasn't sure if I
needed to do anything to eventcal.sql. Since my last email, I edited
that file, but since I apparently didn't need to, will it do any harm?

Also, what shall I do when I'm ready to commit?

Here's the list of tables/fields I added:

added table "recurringdates" :
("id" int(10) unsigned not null auto_increment,
"d" date not null,
"event_id" int(10) unsigned not null,
"recurrence_id" int(10) unsigned not null,
ongoing bool,
primary key ("id") );

added columns to "eventdatetime":
"recurringtype" varchar(255),
"recurs_until" datetime,
"rectypemonth" varchar(255)

Nathan Kern

[Brett Bieber]

On Mon, Jun 28, 2010 at 10:31 AM, Nathan Kern
<nk_ange...@hotmail.com> wrote:
> I think I've taken care of that .xml file. I just wasn't sure if I
> needed to do anything to eventcal.sql. Since my last email, I edited
> that file, but since I apparently didn't need to, will it do any harm?

No harm at all.

> Also, what shall I do when I'm ready to commit?

I'd just make unified .diff files available online, ideally as patches
attached to the issue tracker so we can take a look.

> Here's the list of tables/fields I added:
>
> added table "recurringdates" :
> ("id" int(10) unsigned not null auto_increment,
> "d" date not null,
> "event_id" int(10) unsigned not null,
> "recurrence_id" int(10) unsigned not null,
> ongoing bool,
> primary key ("id") );
>
> added columns to "eventdatetime":
> "recurringtype" varchar(255),
> "recurs_until" datetime,
> "rectypemonth" varchar(255)

Hmm, just simply "d" for the column name in the recurringdates table?
Also, all the other db tables are not plural, could the table be
'recurringdate' ?

[Nathan Kern]

> Hmm, just simply "d" for the column name in the recurringdates table?
> Also, all the other db tables are not plural, could the table be
> 'recurringdate' ?

I'll change it to "date" and "recurringdate". I initially chose "d"
because I had planned to design the table more like 'ongoingcheck'.

Nathan Kern

[Brett Bieber]

I'd just caution against using reserved words. Just some ideas:
eventdate, startdate, recurringdate?

[Nathan Kern]

"recurringdate" has been chosen for both names, then. A new issue has
the outputs of svn diff attached. Although it appears that my changes
to EventListing.php, Day.php, Month.php, Frontend.php, and templates/
default/manager.js are not listed because those files are marked as a
binary type. I'll send the changes for those files soon.

Nathan Kern

[Nathan Kern]

All of the changes should be in the new issue.

Nathan Kern

[Nathan Kern]

My supervisor wants me to add the ability to unlink recurrences of an
event from the master event. Basically, the recurrence info could be
used as a template to create all the recurrences of an event, then
information could be added to each individual recurrence, such as who
is speaking at the event. I already created the function to do this,
but there's a few things I'm not sure about.

First, I don't know whether this option should be a button or a check
box or part of a drop-down menu. I also don't know what a good
descriptive name for this option would be. I get the feeling most
users won't know what it does if all it says is "unlink."

What do you think?

Nathan Kern

[Brett Bieber]

I would check other calendar applications and see what terminology
they've used. Sounds like "Edit instance of recurring event." ? As for
the UI, no clue.

[Seth Meranda]

I'm not sure how feasible this is, but here's my thought:

Give the user the ability to edit an individual event (which is part of a recurring event). If he/she does so, upon save give the user the following option (perhaps a modal alert?):

This event is part of a recurring event. Would you like to edit: only this event, all events in the series, all following events?

Then based on the decision, run the specific functions.

HTH

Seth Meranda

University of Nebraska-Lincoln

[Nathan Kern]

I was already planning on letting the user choose between editing the
single instance or all instances, but I hadn't thought of "all
following events." I'll do that, then. But just so I'm sure I
understand you, you want me to allow the user to edit all instances of
an event that occur on or after the current date being edited,
correct?

Also, there's an issue that I'm not sure how I should handle. On my
phone, I can make recurring events, then edit individual details about
instances, but once I do that, the event is no longer linked to the
other instances. So when I edit another instance and choose "edit all
recurrences," it changes all instances except the ones where I
selected "edit this instance only."

On the other hand, when I choose "edit all recurrences" in the
Evolution calendar system, it changes even the events where I said
"edit this instance only." This could be troublesome if someone were
to edit time information in one instance, say to change it to 10:00
AM, and then edit all instances, to change them to 12:00 PM. If
someone does that, is the system supposed to overwrite the 10:00 AM
setting, or let it stay the same?

> > unl-event-publi...@googlegroups.com<unl-event-publisher%2Bunsu bsc...@googlegroups.com>
> > .

[Seth Meranda]

Also, there's an issue that I'm not sure how I should handle. On my

phone, I can make recurring events, then edit individual details about

instances, but once I do that, the event is no longer linked to the

other instances. So when I edit another instance and choose "edit all

recurrences," it changes all instances except the ones where I

selected "edit this instance only."

This sounds more natural to calendaring systems. It would be hard to define the lines of when and which data should be updated. If a user has elected to break an event from the recurring, it shouldn't be updated by the recurring series.

Seth Meranda

To unsubscribe from this group, send email to unl-event-publi...@googlegroups.com.

[Nathan Kern]

Whew, I was hoping you would pick that one. The other just sounded
like too much work. Anyway, I'll get working on that soon.

On Jul 9, 10:48 am, Seth Meranda <seth...@gmail.com> wrote:
> > Also, there's an issue that I'm not sure how I should handle. On my
>
> phone, I can make recurring events, then edit individual details about
>
> instances, but once I do that, the event is no longer linked to the
>
> other instances. So when I edit another instance and choose "edit all
>
> recurrences," it changes all instances except the ones where I
>
> selected "edit this instance only."
>
> This sounds more natural to calendaring systems. It would be hard to define
> the lines of when and which data should be updated. If a user has elected to
> break an event from the recurring, it shouldn't be updated by the recurring
> series.
>
> Seth Meranda
>

> > > > unl-event-publi...@googlegroups.com<unl-event-publisher%2Bunsu bsc...@googlegroups.com><unl-event-publisher%2Bunsu

[Nathan Kern]

It seems more trouble than it's worth to add an "edit all following
events" option. With the current way things are set up, editing "all
following events" would mean breaking all of those from the recurring
series. Unless I am wrong, this is not desirable.

Also, I'm trying to avoid having to use a modal dialog. If the only
options are "edit this" and "edit all", then I can put these options
in the edit column of the manager. Any more options (or longer
descriptions of the options) seem to take up too much space.

If you do want me to use a modal dialog, do you have any suggestions
in mind?

Nathan Kern

[Seth Meranda]

Nathan:

I like to use modal boxes (or equivalent) as it "forces" the user to focus on answering a question (do you want to edit only this event, or all following). It also allows us to bring in some more context through imagery or supporting text. However, if I'm understanding you correctly, without this option, we're left with a much simpler action. If that's the case then a modal box is likely not needed (unless we are concerned a user won't understand what the options are for).

Let's see what you have and we can work from there if needed.

Thanks!

Seth Meranda

University of Nebraska-Lincoln

--
You received this message because you are subscribed to the Google Groups "UNL Event Publisher" group.
To post to this group, send email to unl-event...@googlegroups.com.

To unsubscribe from this group, send email to unl-event-publi...@googlegroups.com.

[Nathan Kern]

The modal dialog might end up being simpler in the long run, I just
wasn't sure what to do about creating one. There seem to be plenty of
scripts on the internet to do that, but many of them looked rather
style-specific. Oddly enough, though, right after I posted that last
message I found one that looks customizable enough for our purposes
(at http://www.leigeber.com/2008/04/custom-javascript-dialog-boxes/).
I'll commit my recent changes to show you what I did, but then I think
I'll start working on that dialog. I liked the original idea of having
a box appear to inform the user that the event is recurring etc.

So that still leaves us to the "all following events" option. I could
do it, it would just mean splitting up master events. I.e. if you
elect to edit all following events halfway through the series, the
first half will essentially become one set of recurring events and the
second half will be the other. So after you choose this option, any
events made to the second half would not apply to the first half and
vice versa. Now that I think of it, though, this may be the intuitive
choice. Keeping them all under the same recurring series would have
the same issue that I mentioned before with Evolution's calendar
system.

Nathan Kern

[Brett Bieber]

On Mon, Jul 19, 2010 at 7:29 AM, Nathan Kern
<nk_ange...@hotmail.com> wrote:
> I.e. if you
> elect to edit all following events halfway through the series, the
> first half will essentially become one set of recurring events and the
> second half will be the other. So after you choose this option, any
> events made to the second half would not apply to the first half and
> vice versa.

This sounds like a good way to go.

[Nathan Kern]

I just realized I should have made recurringdate.recurrence_id SIGNED,
not UNSIGNED. Is it going to screw anything up if I just change it
right now?

[Brett Bieber]

Hmm... why signed? Shouldn't all the PKs and FKs be unsigned ints?

I don't think it will matter much if you change it now, as long as it
is consistent with all the others.

[Nathan Kern]

Well, because my plan to "unlink" the events is to actually keep track
of which ones are unlinked in the recurringdate table. The ones that
are unlinked will have a negative id equal to the opposite of their
positive id plus one. This is so I can tell which recurrence it was
before it was unlinked.

If it would cause too much trouble, then I'll just add another column
to the table.

Also, there's a difference between recurringdate.id and
recurringdate.recurrence_id. I think recurrence_id is neither a PK nor
a FK.

[Nathan Kern]

When the user chooses to edit all events in a series, should the date
info for that instance show up or for the first instance (i.e. of the
master event)?

Nathan Kern

[Nathan Kern]

Hmm. My last post didn't seem to work. Let's try that again.

I was thinking that when a user wants to edit an event recurrence
other than the first recurrence, that recurrence's eventdatetime
information should show up instead of the first recurrence's info.
This is proving to be much more of a pain than I thought it would be.
Although I'm almost done with it, I want to be sure that this is the
desired behavior in case I'm just wasting time.

Nathan Kern

[Seth Meranda]

If you can get it to work, that would be the preferred method.

Thanks Nathan!

- Seth Meranda

[Nathan Kern]

Okay. The user should be able to edit instances as desired now.

Nathan Kern

[Nathan Kern]

I get some pretty strange results when when I add another
eventdatetime to a recurring event.

Is anyone ever going to want to do something like that?

Nathan Kern

[Brett Bieber]

Hmm, that's an interesting question. I would say yes, but I'm not a
regular user. From my experience, people really hate entering the
details again, so another eventdatetime is really helpful. But another
eventdatetime for an event which is already recurring, maybe that's
not required.

[Nathan Kern]

Due to the unexpected behavior, I'm tempted to disable adding another

eventdatetime to a recurring event.

Nathan Kern

[mdmcginn]

Nathan, I think you should give into that temptation. If I ever wanted
to add another eventdatetime to a recurring event, I could always just
add a second event record with the same title and description.

Michael McGinnis