Home » Eclipse Projects » GEF » creation constraints based on model type
| creation constraints based on model type [message #132861] |
Wed, 19 May 2004 07:26  |
Eclipse User |
|
|
|
Originally posted by: m.hassenforder.uha.fr
Hello,
I design an editorWithPalette application.
I my application I have three kind of components: diagram, container, part.
I have also constraints:
A diagram can contain container but not part
A container can contain part.
I have to implement these constraints as I create the component. I have
designed two LayoutEditPolicies: one for the diagram and one for the
container.
In the getCreateCommand(CreateRequest request) I look at the type of the
NewObject() in the request. If the type is legal I reply with an
associated CreateCommand() else I reply null (no allowed command I presume).
I that the good way to ensure such a constraint or is another place ?
Thanks in advance.
|
|
|
| Re: creation constraints based on model type [message #132949 is a reply to message #132861] |
Wed, 19 May 2004 11:57  |
| Eclipse User |
|
|
|
Originally posted by: eostroukhov.hotmail.com
I would recommend you to return UnexecutableCommand.INSTANCE - it will
clearly indicate that this operation is illegal. Returning null indicates
that you just do nothing. It cost me some bugs to understand the difference
:)
Eugene
"Hassenforder" <m.hassenforder@uha.fr> wrote in message
news:c8f1qa$i6m$1@eclipse.org...
> Hello,
>
> I design an editorWithPalette application.
>
> I my application I have three kind of components: diagram, container,
part.
> I have also constraints:
> A diagram can contain container but not part
> A container can contain part.
>
> I have to implement these constraints as I create the component. I have
> designed two LayoutEditPolicies: one for the diagram and one for the
> container.
> In the getCreateCommand(CreateRequest request) I look at the type of the
> NewObject() in the request. If the type is legal I reply with an
> associated CreateCommand() else I reply null (no allowed command I
presume).
>
> I that the good way to ensure such a constraint or is another place ?
>
> Thanks in advance.
>
>
|
|
|
| Re: creation constraints based on model type [message #132975 is a reply to message #132949] |
Wed, 19 May 2004 13:15 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Hello Eugene,
are you sure about the difference between returning null or returning =
UnexecutableCommand.INSTANCE ?
When EditPart.getCommand(Request) returns null, usualy the tool wich is =
=
handling the current operation shows a special red cursor, wich seems to=
=
show that Gef understands this "null" return as an illegal opertation an=
d =
not just as a command that would do nothing.
In addition to that, I recall having read something about returning null=
=
in an article on gef (maybe the redbook?).
Am I wrong ?
I'm also very confused about the differents ways of signaling an illegal=
=
operation to gef.
I see five ways to do that:
- the method undestandsRequest() of EditPart and EditPolicy(?) returning=
=
false,
- the method getTargetEditPart() of EditPart and EditPolicy returning nu=
ll,
- the method Command.canExecute() returning false,
- the method getCommand() returning null,
- and now your way, the method getCommand() returning =
UnexecutableCommand.INSTANCE...
Can someone explain the differences between these different ways ?
By now, I think that the first two ways should be used to indicate to Ge=
f =
wich EditPart is usualy a valid target for the current operation, and th=
e =
three last ways should be used to indicate to Gef that, although the =
target is usualy valid, for some reason in this particular case, the =
operation isn't valid. But I'm not sure at all about this.
I think a thread on this matter (and answers of the Gods of Gef living i=
n =
this newsgroup :) ), would be very helpfull for everybody.
r=E9gis
On Wed, 19 May 2004 14:57:57 +0300, Eugene Ostroukhov =
<eostroukhov@hotmail.com> wrote:
> I would recommend you to return UnexecutableCommand.INSTANCE - it will=
> clearly indicate that this operation is illegal. Returning null indica=
tes
> that you just do nothing. It cost me some bugs to understand the =
> difference
> :)
>
> Eugene
|
|
|
| Re: creation constraints based on model type [message #133001 is a reply to message #132975] |
Wed, 19 May 2004 14:59 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Feel free to search the newsgroup - this has been answered before. In
summary, when you return null it means no participation from that part. If
you return UnexecutableCommand.INSTANCE, it means you specifically want to
disallow the operation. If everything returns null, and thus no one has
participated, you will also get the not sign that is associated with
UnexecutableCommand.INSTANCE. Choose what makes sense for your application
based on these principles.
<rlemaigr@ulb.ac.be> wrote in message
news:opr780fhpwxn9g2u@xn--pcrgis-dva.mshome.net...
Hello Eugene,
are you sure about the difference between returning null or returning
UnexecutableCommand.INSTANCE ?
When EditPart.getCommand(Request) returns null, usualy the tool wich is
handling the current operation shows a special red cursor, wich seems to
show that Gef understands this "null" return as an illegal opertation and
not just as a command that would do nothing.
In addition to that, I recall having read something about returning null
in an article on gef (maybe the redbook?).
Am I wrong ?
I'm also very confused about the differents ways of signaling an illegal
operation to gef.
I see five ways to do that:
- the method undestandsRequest() of EditPart and EditPolicy(?) returning
false,
- the method getTargetEditPart() of EditPart and EditPolicy returning null,
- the method Command.canExecute() returning false,
- the method getCommand() returning null,
- and now your way, the method getCommand() returning
UnexecutableCommand.INSTANCE...
Can someone explain the differences between these different ways ?
By now, I think that the first two ways should be used to indicate to Gef
wich EditPart is usualy a valid target for the current operation, and the
three last ways should be used to indicate to Gef that, although the
target is usualy valid, for some reason in this particular case, the
operation isn't valid. But I'm not sure at all about this.
I think a thread on this matter (and answers of the Gods of Gef living in
this newsgroup :) ), would be very helpfull for everybody.
r
|
|
|
| Re: creation constraints based on model type [message #133014 is a reply to message #132975] |
Wed, 19 May 2004 14:03 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
If all contributions to the interaction are NULL, then there is no
difference between NULL and the UE command. But, if you aren't sure if
other parts are contributing, it is safer to return UEC.
<rlemaigr@ulb.ac.be> wrote in message
news:opr780fhpwxn9g2u@xn--pcrgis-dva.mshome.net...
Hello Eugene,
are you sure about the difference between returning null or returning
UnexecutableCommand.INSTANCE ?
When EditPart.getCommand(Request) returns null, usualy the tool wich is
handling the current operation shows a special red cursor, wich seems to
show that Gef understands this "null" return as an illegal opertation and
not just as a command that would do nothing.
In addition to that, I recall having read something about returning null
in an article on gef (maybe the redbook?).
Am I wrong ?
I'm also very confused about the differents ways of signaling an illegal
operation to gef.
I see five ways to do that:
- the method undestandsRequest() of EditPart and EditPolicy(?) returning
false,
- the method getTargetEditPart() of EditPart and EditPolicy returning null,
- the method Command.canExecute() returning false,
- the method getCommand() returning null,
- and now your way, the method getCommand() returning
UnexecutableCommand.INSTANCE...
Can someone explain the differences between these different ways ?
By now, I think that the first two ways should be used to indicate to Gef
wich EditPart is usualy a valid target for the current operation, and the
three last ways should be used to indicate to Gef that, although the
target is usualy valid, for some reason in this particular case, the
operation isn't valid. But I'm not sure at all about this.
I think a thread on this matter (and answers of the Gods of Gef living in
this newsgroup :) ), would be very helpfull for everybody.
r
|
|
|
| Re: creation constraints based on model type [message #133025 is a reply to message #132975] |
Wed, 19 May 2004 14:07 |
| Eclipse User |
|
|
|
Originally posted by: eostroukhov.hotmail.com
> I'm also very confused about the differents ways of signaling an illegal
> operation to gef.
>
> I see five ways to do that:
> - the method undestandsRequest() of EditPart and EditPolicy(?) returning
> false,
Indicates that this particular edit part does not know of such requests and
will never handle it.
> - the method getTargetEditPart() of EditPart and EditPolicy returning
null,
Tells that this edit part doesn't know any edit parts able to handle this
request - i.e. edit parts may return parent to hadle this type of requests.
> - the method Command.canExecute() returning false,
Tells that this command cannot be executed right now. I.e. it has invalid
parameters. In time (i.e. when the tool will update the parameters) it will
be able to execute.
> - the method getCommand() returning null,
Edit part does nothing to handle the request.
> - and now your way, the method getCommand() returning
UnexecutableCommand.INSTANCE...
It's actually similar to returning false from canExecute().
I found principal difference when you handle group request (i.e. group
move). If one of you edit part will return null, it will not be moved but
other edit parts will be moved. If one of the editparts will return
UnexecutableCommand.INSTANCE or returned command will return false from the
canExecute no editParts will be moved.
I.e. I don't allow children to be dropped if their bounds are not completely
in the parent's client area. When I returned null, it was ok if one child
was dragged between parents but when several children were dragged between
parents all children that had null returned from the createAddCommand method
were lost (they participated in orphaning but skipped the adding phase).
Everythin fixed when I returned UnexecutableCommand.INSTANCE from the
method.
Eugene
|
|
|
| Re: creation constraints based on model type [message #133038 is a reply to message #132861] |
Wed, 19 May 2004 14:08 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Hello Hassenforder,
I ask also to myself a lot of questions about the good places to check =
constraints. Here is a reflexion that could be usefull to you, but I don=
't =
know if I'm doing good, so don't trust my advices too much.
I've made myself an editor like yours, with diagram containing container=
s, =
containing parts. In fact, in my editor, the containers could contain =
other container also, so the problem was a little more complicated.
At the beginning I was doing things just like you: different layout =
editpolicies with getCommand(Request req) returning null when =
req.getNewObject() was not of the appropriated type for the container =
hosting the LayoutEditPolicy.
But by doing things like that, I ran into various problems:
1) Let's say you want to create a container in your diagram with a =
creation tool. When the mouse pointer is above the diagram, everything =
goes right. But when you are above an existing container, the mouse =
pointer turns into a red cursor indicating an illegal operation and you =
=
can't perform the creation of your new container. Reason of that is as y=
ou =
are above two stacked EditParts (a diagram and a container), each one wi=
th =
a LayoutEditPolicy installed and thus being two appropriate target for a=
=
creation request. In this case, Gef chooses the top most EditPart as =
target of the create request, and unfortunatly this EditPart is the =
container, not the diagram, so the getCommand of the container returns =
null because the type of the new object is not Part but Container and th=
e =
cursor turns red, preventing you to create your new Container.
In the case of a diagram with an XYLayoutManager, it's not a big problem=
=
because you can always create your new container elsewhere then move it =
=
where you want. But if the diagram (or a parent container of the =
containers) is layed out by ToolbarLayout or FlowLayout, with no place =
between the elements, it can become a very big problem.
2) Maybe the constraint that you're talking about is not the only one. =
Maybe the contraints to check are function of a lot of factors and not =
only the type of the new object...It will make your getXXXCommand() and =
=
your EditPolicies very very complicated.
The problem 1) can be easily solved like that:
In fact, you want that gef makes your creation request "go through" all =
=
the containers for wich it is illegal, and find the first container belo=
w =
the mouse pointer for wich your creation request is legal.
Gef uses the getTargetEditPart() of EditPart and EditPolicy method to fi=
nd =
an appropriate target for a request. The request "go through" all the =
EditParts for wich this method returns null and finally reachs the =
EditPart returned by the first method getTargetEditPart() returning othe=
r =
than null.
So you can do wath you want by redifining the method =
getTargetEditPart(Request) of the layout EditPolicy installed on your =
containers, and make it either return null if the type of the new Object=
=
is not good or return getHost() if the type is good.
If the creation tool is the only way to create new objects, you don't ne=
ed =
more than that, you don't need anymore to check your constraint in the =
getCreationCommand(request) method because only valid requests will reac=
h =
this method.
The problem 2) can be solved like that:
Instead of checking all the constraints in the EditPolicies, why not to =
=
check them in the method canExecute() of Command ? I think this method w=
as =
made for that purpose but maybe I'm wrong.
Let me know is this has help you and good luck,
r=E9gis
On Wed, 19 May 2004 09:26:09 +0200, Hassenforder <m.hassenforder@uha.fr>=
=
wrote:
> Hello,
>
> I design an editorWithPalette application.
>
> I my application I have three kind of components: diagram, container, =
=
> part.
> I have also constraints:
> A diagram can contain container but not part
> A container can contain part.
>
> I have to implement these constraints as I create the component. I hav=
e =
> designed two LayoutEditPolicies: one for the diagram and one for the =
> container.
> In the getCreateCommand(CreateRequest request) I look at the type of t=
he =
> NewObject() in the request. If the type is legal I reply with an =
> associated CreateCommand() else I reply null (no allowed command I =
> presume).
>
> I that the good way to ensure such a constraint or is another place ?
>
> Thanks in advance.
|
|
|
| Re: creation constraints based on model type [message #133261 is a reply to message #133001] |
Thu, 20 May 2004 13:43 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
thx for your explanations.
On Wed, 19 May 2004 09:59:18 -0500, Whitney Sorenson <none@us.ibm.com> =
wrote:
> Feel free to search the newsgroup - this has been answered before. In
> summary, when you return null it means no participation from that part=
.. =
> If
> you return UnexecutableCommand.INSTANCE, it means you specifically wan=
t =
> to
> disallow the operation. If everything returns null, and thus no one ha=
s
> participated, you will also get the not sign that is associated with
> UnexecutableCommand.INSTANCE. Choose what makes sense for your =
> application
> based on these principles.
|
|
|
| Re: creation constraints based on model type [message #133274 is a reply to message #133025] |
Thu, 20 May 2004 13:47 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
> "I.e. I don't allow children to be dropped if their bounds are not =
> completely
in the parent's client area. When I returned null, it was ok if one chil=
d
was dragged between parents but when several children were dragged betwe=
en
parents all children that had null returned from the createAddCommand =
method
were lost (they participated in orphaning but skipped the adding phase).=
Everythin fixed when I returned UnexecutableCommand.INSTANCE from the
method."
Now you mention it, I had such a problem myself (orphan without add) and=
I =
couldn't solve it. Thanks for your answer and the explanations.
r=E9gis
|
|
|
| Re: creation constraints based on model type [message #133288 is a reply to message #133014] |
Thu, 20 May 2004 13:50 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Ok.
I didn't keep in mind the all group request and multiple participations =
=
thing, that's why I was confused about the differences between null and =
=
uec. Now I understand better, thank you for your answer.
r=E9gis
On Wed, 19 May 2004 10:03:59 -0400, Randy Hudson <none@us.ibm.com> wrote=
:
> If all contributions to the interaction are NULL, then there is no
> difference between NULL and the UE command. But, if you aren't sure i=
f
> other parts are contributing, it is safer to return UEC.
|
|
|
| Re: creation constraints based on model type [message #133785 is a reply to message #133038] |
Mon, 24 May 2004 09:26 |
| Eclipse User |
|
|
|
Originally posted by: m.hassenforder.uha.fr
hello,
I am back to my office (We had have holidays since 20 may)
Thank you for the valuable replies.
I have to look carefully because I think that I could ran into the same
problems (container in container, etc.). For example : I am currently
looking how to forward a move from a part to the enclosed container and
such a problem could be solved using the container stack.
So, for one question I have three replies :
1) the differences between null and uec commands.
2) the initial idea is not definitively wrong, for the first prototype
it can be enough.
3) I can enhance my design taking into account the canExecute() method.
Earlier I think that this method was more connected to the structure of
GEF than to the semantic of my application.
Thanks all for your explanations
rlemaigr@ulb.ac.be wrote:
> Hello Hassenforder,
>
> I ask also to myself a lot of questions about the good places to check
> constraints. Here is a reflexion that could be usefull to you, but I
> don't know if I'm doing good, so don't trust my advices too much.
>
> I've made myself an editor like yours, with diagram containing
> containers, containing parts. In fact, in my editor, the containers
> could contain other container also, so the problem was a little more
> complicated.
>
> At the beginning I was doing things just like you: different layout
> editpolicies with getCommand(Request req) returning null when
> req.getNewObject() was not of the appropriated type for the container
> hosting the LayoutEditPolicy.
>
> But by doing things like that, I ran into various problems:
>
> 1) Let's say you want to create a container in your diagram with a
> creation tool. When the mouse pointer is above the diagram, everything
> goes right. But when you are above an existing container, the mouse
> pointer turns into a red cursor indicating an illegal operation and you
> can't perform the creation of your new container. Reason of that is as
> you are above two stacked EditParts (a diagram and a container), each
> one with a LayoutEditPolicy installed and thus being two appropriate
> target for a creation request. In this case, Gef chooses the top most
> EditPart as target of the create request, and unfortunatly this
> EditPart is the container, not the diagram, so the getCommand of the
> container returns null because the type of the new object is not Part
> but Container and the cursor turns red, preventing you to create your
> new Container.
> In the case of a diagram with an XYLayoutManager, it's not a big
> problem because you can always create your new container elsewhere then
> move it where you want. But if the diagram (or a parent container of
> the containers) is layed out by ToolbarLayout or FlowLayout, with no
> place between the elements, it can become a very big problem.
>
> 2) Maybe the constraint that you're talking about is not the only one.
> Maybe the contraints to check are function of a lot of factors and not
> only the type of the new object...It will make your getXXXCommand() and
> your EditPolicies very very complicated.
>
>
> The problem 1) can be easily solved like that:
>
> In fact, you want that gef makes your creation request "go through" all
> the containers for wich it is illegal, and find the first container
> below the mouse pointer for wich your creation request is legal.
> Gef uses the getTargetEditPart() of EditPart and EditPolicy method to
> find an appropriate target for a request. The request "go through" all
> the EditParts for wich this method returns null and finally reachs the
> EditPart returned by the first method getTargetEditPart() returning
> other than null.
> So you can do wath you want by redifining the method
> getTargetEditPart(Request) of the layout EditPolicy installed on your
> containers, and make it either return null if the type of the new
> Object is not good or return getHost() if the type is good.
> If the creation tool is the only way to create new objects, you don't
> need more than that, you don't need anymore to check your constraint in
> the getCreationCommand(request) method because only valid requests will
> reach this method.
>
> The problem 2) can be solved like that:
>
> Instead of checking all the constraints in the EditPolicies, why not to
> check them in the method canExecute() of Command ? I think this method
> was made for that purpose but maybe I'm wrong.
>
>
> Let me know is this has help you and good luck,
>
> régis
>
>
> On Wed, 19 May 2004 09:26:09 +0200, Hassenforder
> <m.hassenforder@uha.fr> wrote:
>
>> Hello,
>>
>> I design an editorWithPalette application.
>>
>> I my application I have three kind of components: diagram, container,
>> part.
>> I have also constraints:
>> A diagram can contain container but not part
>> A container can contain part.
>>
>> I have to implement these constraints as I create the component. I
>> have designed two LayoutEditPolicies: one for the diagram and one for
>> the container.
>> In the getCreateCommand(CreateRequest request) I look at the type of
>> the NewObject() in the request. If the type is legal I reply with an
>> associated CreateCommand() else I reply null (no allowed command I
>> presume).
>>
>> I that the good way to ensure such a constraint or is another place ?
>>
>> Thanks in advance.
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 22:52:58 GMT 2024
Powered by FUDForum. Page generated in 0.03908 seconds |
] 
Search
Help
Register
Login
Home
