On 28 April 2011 12:17, Graham Binns <email address hidden> wrote:
> On 28 April 2011 09:49, Gavin Panella <email address hidden> wrote:
[...]
>> The call to context.createBug(...) fires an ObjectCreatedEvent, which
>> is probably where notifications to subscribers are sent... *before*
>> the status is updated.
>
> It could be this or it could be the transitionToStatus() call that's
> doing the notification.
I'm reasonably sure that transitionToStatus() does not notify().
Instead I think a view takes care of firing an ObjectModifiedEvent
(once all changes have been applied), and the web service machinery
does the same for API calls over the wire.
[...]
>> Now, status can be set on the CreateBugParams object that is passed
>> into createBug(), but not importance for example, so a general fix is
>> not possible down that road without adding more to CreateBugParams.
>>
>> A general fix might involve delaying the notification of the
>> ObjectCreatedEvent within createBug(). createBugWithoutTarget() is an
>> example of how a similar problem has been solved in the past.
>
> Right. I'm broadly more in favour of fixing CreateBugParams to accept
> more options than futzing around with when notify() happens and which
> method's responsible for it.
I think it might be a bad idea to bypass transitionToStatus() because
it does a *lot* more than set the bug's status. It's probably true of
all the transitionTo*() methods.
The very end of BugSet.createBug() is:
# Tell everyone. notify(event)
# Calculate the bug's initial heat. bug.updateHeat()
return bug
The call to updateHeat() could probably come before notify():
# Calculate the bug's initial heat. bug.updateHeat()
# Tell everyone. notify(event)
return bug
Then it's only a short hop to having two functions:
On 28 April 2011 12:17, Graham Binns <email address hidden> wrote: createBug( ...) fires an ObjectCreatedEvent, which tus() call that's
> On 28 April 2011 09:49, Gavin Panella <email address hidden> wrote:
[...]
>> The call to context.
>> is probably where notifications to subscribers are sent... *before*
>> the status is updated.
>
> It could be this or it could be the transitionToSta
> doing the notification.
I'm reasonably sure that transitionToSta tus() does not notify().
Instead I think a view takes care of firing an ObjectModifiedEvent
(once all changes have been applied), and the web service machinery
does the same for API calls over the wire.
[...] tTarget( ) is an
>> Now, status can be set on the CreateBugParams object that is passed
>> into createBug(), but not importance for example, so a general fix is
>> not possible down that road without adding more to CreateBugParams.
>>
>> A general fix might involve delaying the notification of the
>> ObjectCreatedEvent within createBug(). createBugWithou
>> example of how a similar problem has been solved in the past.
>
> Right. I'm broadly more in favour of fixing CreateBugParams to accept
> more options than futzing around with when notify() happens and which
> method's responsible for it.
I think it might be a bad idea to bypass transitionToSta tus() because
it does a *lot* more than set the bug's status. It's probably true of
all the transitionTo*() methods.
The very end of BugSet.createBug() is:
# Tell everyone.
notify( event)
# Calculate the bug's initial heat.
bug.updateHeat ()
return bug
The call to updateHeat() could probably come before notify():
# Calculate the bug's initial heat.
bug.updateHeat ()
# Tell everyone.
notify( event)
return bug
Then it's only a short hop to having two functions:
def createBug(self, bug_params): ndEvent( bug_params)
notify( event)
bug, event = self.createBugA
return bug
def createBugAndEve nt(self, bug_params):
...
return bug, event
FileBugViewBase .submit_ bug_action can call createBugAndEve nt(), muck
around with the bug's state, then notify().