|
| Re: Restrict model modifications - ItemProvider.createCommand? [message #423898 is a reply to message #423893] |
Thu, 09 October 2008 10:40   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Mario,
Comments below.
Mario Winterer wrote:
> Hi!
>
> I wonder about how to best restrict the model modifications that can
> be done by the user.
Shackles. :-P
>
> More precise I want some model modification operations to be disabled
> in certain situations or to behave somehow special according to user
> defined settings (e.g. special DnD or cut/copy/paste behaviour).
>
> I thought of overriding the create*Command-methods in my
> ItemProviders. E.g. if an AdressBook-object is read-only, I'd override
> AddressBookItemProvider.createAddCommand(...) to return
> UnexecutableCommand.INSTANCE instead of the original AddCommand.
Yes, thats the approach I'd use.
>
> But is it wise to disable basic commands like SetCommand or AddCommand?
Presumably you'd do it based on some condition and that condition would
apply no matter one. Certainly you need to keep in mind that add
command would be used not only to help support a drag and drop, but
also, paste, and create child. So if you want disable only the higher
level things, it might be better to focus on those instead.
> Not only user-triggered actions will be disabled, but also
> "programatic" ones. For example in our application the user must not
> modify a read-only AddressBook object, but the application must still
> be able to update it (e.g. because it was changed on the server).
Is the application using commands to update it. It seems unlikely that
server changes would be done as commands that could then be undone. It
seems more likely they'd operate directly on the model (and that the
undo stack is flushed after such a direct model change).
>
> The only way this can be done I think, is by not using the factory
> method in all cases.
>
> Is there a rule when to use AddCommand.create(...) and when to use the
> constructor? Maybe it is wise to use the constructor for all
> "internal" modifications that must bypass the restrictions and to use
> the factory methods if the command is directly triggered by the user.
Generally we use the create methods as a factory, which delegates to the
item providers, which implement the details of the factory, which
ultimately need to create instances of commands without getting into a
circularity.
>
> I'd be grateful for your minds!
I'm a bit doubtful that server side changes should be enacted with
commands though. To me that implies they would end up being undoable...
>
>
> Thanks,
> Mario
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Restrict model modifications - ItemProvider.createCommand? [message #423902 is a reply to message #423898] |
Thu, 09 October 2008 11:33 |
Mario Winterer
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Thanks Ed.
Comments below too...
Ed Merks schrieb:
> Mario,
>
> Comments below.
>
>
> Mario Winterer wrote:
>> Hi!
>>
>> I wonder about how to best restrict the model modifications that can
>> be done by the user.
> Shackles. :-P
Great idea! Together wit gags this will solve all our (user-)problems! ;-)
>>
>> More precise I want some model modification operations to be disabled
>> in certain situations or to behave somehow special according to user
>> defined settings (e.g. special DnD or cut/copy/paste behaviour).
>>
>> I thought of overriding the create*Command-methods in my
>> ItemProviders. E.g. if an AdressBook-object is read-only, I'd override
>> AddressBookItemProvider.createAddCommand(...) to return
>> UnexecutableCommand.INSTANCE instead of the original AddCommand.
> Yes, thats the approach I'd use.
>>
>> But is it wise to disable basic commands like SetCommand or AddCommand?
> Presumably you'd do it based on some condition and that condition would
> apply no matter one. Certainly you need to keep in mind that add
> command would be used not only to help support a drag and drop, but
> also, paste, and create child. So if you want disable only the higher
> level things, it might be better to focus on those instead.
>> Not only user-triggered actions will be disabled, but also
>> "programatic" ones. For example in our application the user must not
>> modify a read-only AddressBook object, but the application must still
>> be able to update it (e.g. because it was changed on the server).
> Is the application using commands to update it. It seems unlikely that
> server changes would be done as commands that could then be undone. It
> seems more likely they'd operate directly on the model (and that the
> undo stack is flushed after such a direct model change).
You are absolutely right! Server-updates via commands don't make sense.
That was just a fictious scenario to keep things simple...
But in our real-world scenario, the user is not allowed to add, remove
or change offer items of an offer. But the user is allowed to let the
price of an offer item be calculated automatically (which should be
undoable, indeed). For some other reason we use a ReplaceCommand to
replace the entire item. If my item provider obviates all structural
modifications (including ReplaceCommand), the auto-pricing mechanism
would fail too.
One way to solve that problem is to create a command via constructor if
the restrictions should be bypassed...
>>
>> The only way this can be done I think, is by not using the factory
>> method in all cases.
>>
>> Is there a rule when to use AddCommand.create(...) and when to use the
>> constructor? Maybe it is wise to use the constructor for all
>> "internal" modifications that must bypass the restrictions and to use
>> the factory methods if the command is directly triggered by the user.
> Generally we use the create methods as a factory, which delegates to the
> item providers, which implement the details of the factory, which
> ultimately need to create instances of commands without getting into a
> circularity.
>>
>> I'd be grateful for your minds!
> I'm a bit doubtful that server side changes should be enacted with
> commands though. To me that implies they would end up being undoable...
See above...
>>
>>
>> Thanks,
>> Mario
|
|
|
Powered by
FUDForum. Page generated in 0.04768 seconds
] 
Search
Help
Register
Login
Home
