On 10/5/10 6:11 PM, Ed Leafe wrote:
>
> On Oct 5, 2010, at 7:38 PM, Paul McNett wrote:
>
>> When the user chooses to delete a record, the form's delete() first checks
>> the return
>> value of form.beforeDelete(). If nothing returned, it calls biz.delete(). If
>> that
>> fails, the form displays the error message returned.
>>
>> This seems sane. However, I like to keep almost all my code in the
>> bizobj-layer, not
>> the form layer, and so I code my beforeDelete() rules at the bizobj layer.
>> If I
>> forget to make a binding like:
>>
>> (in my form)
>> def beforeDelete(self):
>> return self.getBizobj().beforeDelete()
>>
>> then my user ends up having to answer 'yes' to the dForm's default "are you
>> sure you
>> want to delete?" only to have it fail with the bizobj's beforeDelete()
>> message.
>
>>
>> I'm tempted to make a patch to dForm.delete() that also checks the return
>> value of
>> the bizobj's beforeDelete() method, and fails immediately if something is
>> returned.
>
> The before* methods are all hooks, so if you wanted to do something
> along those lines, you'd have to create a _beforeDelete() that, if
> successful, calls the hook beforeDelete(), so that users won't have to worry
> about overwriting framework code.
I wasn't going to overwrite the hook code. I was going to do, in dForm.delete()
(pseudocode):
{{{
msg = self.beforeDelete():
if msg in (None, ""):
msg = bizobj.beforeDelete()
if msg:
dabo.ui.stop("Delete failed with response:\n" % msg)
return
# normal processing
}}}
But this would result in the bizobj's beforeDelete() being called twice, which
doesn't seem right and it may assume too much: other users may want to actually
do
stuff in beforeDelete() beyond merely finding out if a deletion would be
allowed.
> That being said, how often does this happen? Do users frequently try to
> delete things that they don't have rights to? If so, I would consider an
> interface update that would disable the button/menu for deletion if they
> can't delete. In the bizobj, move the logic to test deletion permission into
> its own method, and set the DynamicEnabled to that method. Then have your
> bizobj's beforeDelete() check the same method, since deletions can
> potentially come from outside of your UI.
The types of rules I'm testing against are along the lines of not deleting
customers
if orders exist for that customer. It is pretty common in my bizobj classes.
But I
think you are right about separating this from specific to beforeDelete() at
the
bizobj layer. Not a biggie to code my forms to check this biz method before
allowing
delete (and in addition greying out the delete button perhaps). I like letting
them
try to delete and then getting a message telling them why it wasn't allowed,
versus
just disabling the option and leaving them wondering why it isn't enabled.
Deletions
of master records are hopefully rare unless the user is just playing around or
testing.
Paul
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/[email protected]
