Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Restrict model modifications - ItemProvider.createCommand?
Restrict model modifications - ItemProvider.createCommand? [message #423893] Thu, 09 October 2008 08:38 Go to next message
Mario Winterer is currently offline Mario WintererFriend
Messages: 136
Registered: July 2009
Senior Member
Hi!

I wonder about how to best restrict the model modifications that can be
done by the user.

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.

But is it wise to disable basic commands like SetCommand or AddCommand?
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).

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.

I'd be grateful for your minds!


Thanks,
Mario
Re: Restrict model modifications - ItemProvider.createCommand? [message #423898 is a reply to message #423893] Thu, 09 October 2008 10:40 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30825
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
Re: Restrict model modifications - ItemProvider.createCommand? [message #423902 is a reply to message #423898] Thu, 09 October 2008 11:33 Go to previous message
Mario Winterer is currently offline Mario WintererFriend
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
Previous Topic:EMF Serialization Problem
Next Topic:Use annotations in JET template
Goto Forum:
  


Current Time: Tue Jan 28 18:09:35 GMT 2020

Powered by FUDForum. Page generated in 0.02095 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top