David, Sorry it took so long to reply to this - I've been giving it a lot of thought before answering.
I think it would be best to just have the one WorkEffort, and any changes made to recurring instances of it would be made to the original copy. On a side note, the implementation here has some good designs and some bad designs. I'm trying to be careful to port over the good designs and not the bad ones. I came to the conclusion that using the "dummy" WorkEfforts was a bad design. -Adrian --- On Thu, 9/18/08, David E Jones <[EMAIL PROTECTED]> wrote: > From: David E Jones <[EMAIL PROTECTED]> > Subject: Re: Discussion: Recurring Events > To: [email protected] > Date: Thursday, September 18, 2008, 5:05 AM > On Sep 18, 2008, at 5:02 AM, Adrian Crum wrote: > > > --- On Wed, 9/17/08, Adrian Crum > <[EMAIL PROTECTED]> wrote: > >> I would like to start working on connecting the > temporal > >> expressions > >> code to recurring events. Before I begin, I want > to make > >> sure I > >> understand the requirements and where things > should land. > >> > >> The WorkEffort entity already has a > RecurrenceInfoId field, > >> so adding a > >> temporal expression ID field to that is obvious. > > > > So, how do we want this to work? On my local copy, I > changed the > > WorkEffortServices.getWorkEffortEventsByPeriod(...) > method so that > > recurring event info is used to create > "dummy" work efforts that are > > added to the results. If a user changes anything in > the "dummy" work > > effort and saves it, then a work effort is created. > > > > How does that sound? Does anyone have any other ideas? > > At what point did you create the new WorkEffort records? > What it when > they viewed the recurring event, or when they change > something based > on a recurring event (probably along with a question of > change just > this event or the entire series)? > > -David
