- From: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
- Date: Tue, 21 May 2013 07:20:03 +0000
- To: Mounir Lamouri <mounir@lamouri.fr>, "public-sysapps@w3.org" <public-sysapps@w3.org>
El 15/05/13 18:44, "Mounir Lamouri" <mounir@lamouri.fr> escribió: > > >Another side effect of that proposal is that ScheduledTask has to be >constructed instead of being returned by the add() method. This is >mostly because working with objects seems nicer to me and others are >likely to disagree ;). Though, some possibilities that are being enabled >by that is to do: > var t = []; > t.push(new ScheduledTask(new Date() + delay, "current", {})); > t.push(new ScheduledTask(new Date() + delay, "none", {}); > taskScheduler.add(t); >(IOW, it allows getting an array of ScheduledTasks in add().) > >This said, having a constructor for ScheduledTask would change a bit the >id behaviour and every construction should generate a uuid that would be >used when saving the object into the database. The backend would no >longer return an id matching it needs. I do not think this is terrible >but some might disagree. > I assume that the id attribute will be generated (possibly lazily) once the ScheduledTask object is constructed by the platform, right? The ScheduledTask id is important for the app as it could be needed later for removing the task if necessary. That in practice means that we would need a method in the scheduler to remove a ScheduledTask by id. > >Thanks, >-- >Mounir > > ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Received on Tuesday, 21 May 2013 07:20:35 UTC