On Wed, Sep 12, 2012 at 11:46 AM, Mario Gudelj <mario.gud...@gmail.com> wrote: > I had to do the same thing recently. I had to grab the frequency, interval > etc. (used rrule for that) and then had to look at the first event instance > and create multiple instances from that event inside the view. If you create > a series model and use it as a foreign key in your event to keep on top of > everything it should work.
You mean it should work with keeping per-date attendance records you mean? cheers L. > > -m > > On 12 September 2012 07:31, Lachlan Musicman <data...@gmail.com> wrote: >> >> On Tue, Sep 11, 2012 at 5:15 PM, Jani Tiainen <rede...@gmail.com> wrote: >> > >> > Rather than creating individual series of events from recurring I would >> > do a >> > concept called "recurring event". So it would be just a single event >> > that is >> > projected to spesific days as necessary. It requires a slightly more >> > work >> > but it's easier to maintain - for example entry would just state: >> > >> > recurring = True >> > frequence = WEEKLY >> > start_date = 2012-09-11 >> > end_date = 2012-12-01 >> > start_time = 09:00 >> > end_time = 10:00 >> > >> > Then I would roll out custom non-database concept of "calendar day" that >> > would be projected from database using both individual entries and >> > recurring >> > entries. >> > >> > Later on it would be very easy to modify existing recurring events and >> > for >> > example add cancellation of single event by creating overriding events >> > concept. >> > >> > This way amount of data will be kept relatively small, it's much easier >> > to >> > read and modify. Of course drawback is that you need top level >> > mechanisms to >> > work with single calendar entries that map to your database >> > representation. >> >> Great, and obvious, idea - unfortunately a bad fit. Each event needs >> to be an object as there are student attendance records and staff >> attendance records linked to each individually. >> >> I was thinking about it last night and it occurred to me that instead >> of using the admin interface I should just write my own form and then >> do the multiple object creation in the view - it makes sense to me, >> although I'm sure I've miffed something up. >> >> Other ideas still welcome. >> >> cheers >> L. >> >> >> >> -- >> ...we look at the present day through a rear-view mirror. This is >> something Marshall McLuhan said back in the Sixties, when the world >> was in the grip of authentic-seeming future narratives. He said, “We >> look at the present through a rear-view mirror. We march backwards >> into the future.” >> >> http://www.warrenellis.com/?p=14314 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-users@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. -- ...we look at the present day through a rear-view mirror. This is something Marshall McLuhan said back in the Sixties, when the world was in the grip of authentic-seeming future narratives. He said, “We look at the present through a rear-view mirror. We march backwards into the future.” http://www.warrenellis.com/?p=14314 -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
