Home » Eclipse Projects » GEF » "One model - many edit parts" problem!
|
| Re: "One model - many edit parts" problem! [message #218460 is a reply to message #218444] |
Sun, 25 June 2006 13:40   |
Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
kiril mitov wrote:
> Hi all,
> Maybe this problem has been discused before but I just could not find the
> solution of my problem in the previous newsgroup posts and in
> bugs.eclipse.org...
>
> I have a class called VariablesHolder with tree method getInVariables(),
> getOutVariables(), and getInOutVariables().
> The edit part for the VariablesHolder is called VariablesHolderEditPart.
> The method getModelChildren() of the VariablesHolderEditPart looks like
> this:
>
> protected List getModelChildren() {
> List list = new ArrayList();
> list.addAll(getHolder().getInVariables());
> list.addAll(getHolder().getOutVariables());
> list.addAll(getHolder().getInOutVariables();
> return list;
> }
> Every variable is presented with an edit part. And everything works fine.
>
> I encountered a problem when I tried to present the inout variables with
> two edit part. So every inout variable must have two edit parts.
> It should be possible to achive such functionality.
>
> So to create two edit parts I looked in the
> AbstractEditPart::refreshChildren and decide to override this method so
> that when I encounter an inout variable I will create two edit parts.
> But then I noticed the following sentence in the documentation of the
> method:
> "* This method should <em>not</em> be overridden."
>
> So my question is how can I achive the functionality of "one model may
> parts" when I should not override this method?
>
> Ofcourse the documentation of the method do not stop me from overriding
> it, but is there a way to solve my problem without overriding the
> refrehsChildren method?
>
> And if I am to override refreshChildren() what consequence should I
> expect? Anything special?
>
> Thank you in advance...
What are you trying to achieve by having 2 edit parts use 1 model within the
same parent edit part? Perhaps there is another, better way to achieve
this.
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
|
|
|
| Re: "One model - many edit parts" problem! [message #218475 is a reply to message #218460] |
Mon, 26 June 2006 09:40 |
 kiril mitov
Messages: 128
Registered: July 2009 |
Senior Member |
|
|
Thanks for the reply Gilbert...
Whell, as I said I have in, out, and inout variables.
A variable of type IN is represented by one edit part that shows some
information for the variable. The same applies for an OUT variable.
But an INOUT variable must be represented with two edit parts - one that
shows the "in" information for the inout variable and one that shows the
"out" information for the inout variable.
From my point of view, and for the editor I am developing, It will be very
I mean very user friednly to use two edit parts for the same model and
this parts to be in the same parent.
So, for this custom case I am sure that having "one model - many edit
parts" is a very good solution...
CL [dnoyeb] Gilbert wrote:
> kiril mitov wrote:
>> Hi all,
>> Maybe this problem has been discused before but I just could not find the
>> solution of my problem in the previous newsgroup posts and in
>> bugs.eclipse.org...
>>
>> I have a class called VariablesHolder with tree method getInVariables(),
>> getOutVariables(), and getInOutVariables().
>> The edit part for the VariablesHolder is called VariablesHolderEditPart.
>> The method getModelChildren() of the VariablesHolderEditPart looks like
>> this:
>>
>> protected List getModelChildren() {
>> List list = new ArrayList();
>> list.addAll(getHolder().getInVariables());
>> list.addAll(getHolder().getOutVariables());
>> list.addAll(getHolder().getInOutVariables();
>> return list;
>> }
>> Every variable is presented with an edit part. And everything works fine.
>>
>> I encountered a problem when I tried to present the inout variables with
>> two edit part. So every inout variable must have two edit parts.
>> It should be possible to achive such functionality.
>>
>> So to create two edit parts I looked in the
>> AbstractEditPart::refreshChildren and decide to override this method so
>> that when I encounter an inout variable I will create two edit parts.
>> But then I noticed the following sentence in the documentation of the
>> method:
>> "* This method should <em>not</em> be overridden."
>>
>> So my question is how can I achive the functionality of "one model may
>> parts" when I should not override this method?
>>
>> Ofcourse the documentation of the method do not stop me from overriding
>> it, but is there a way to solve my problem without overriding the
>> refrehsChildren method?
>>
>> And if I am to override refreshChildren() what consequence should I
>> expect? Anything special?
>>
>> Thank you in advance...
> What are you trying to achieve by having 2 edit parts use 1 model within the
> same parent edit part? Perhaps there is another, better way to achieve
> this.
|
|
|
| Re: "One model - many edit parts" problem! [message #218515 is a reply to message #218475] |
Mon, 26 June 2006 18:58 |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
The most GEF centric way would be to return a single edit part, and that
edit part will have two children. One child will be the in and one will be
the out. The single edit part you return can have a free form figure just
like the other containers often do. So it is not seen but its two children
are.
You really can not have two edit parts with the same model since that is not
gefs architecture. There is a map that maps models to edit parts and it
would not work well if you did that.
The other alternative is to create two mini models for each in-out model.
One representing in and one representing out. So when the parent is asked
for all children, you return the ins and outs, and then these sub/mini
models. Which can be simple wrappers around the actual model with an added
method
class InModel implements MainModel {
public boolean isIn(){ return true;}
}
class OutModel implements MainModel {
public boolean isIn(){return false;}
}
Its probably adviseable to hold onto the instances and return the same ones
each time else GEF may dump and recreate the editparts when it does not
need to.
The models you give to your views do not have to match exactly your true
models.
CL
kiril mitov wrote:
> Thanks for the reply Gilbert...
> Whell, as I said I have in, out, and inout variables.
> A variable of type IN is represented by one edit part that shows some
> information for the variable. The same applies for an OUT variable.
> But an INOUT variable must be represented with two edit parts - one that
> shows the "in" information for the inout variable and one that shows the
> "out" information for the inout variable.
>
> From my point of view, and for the editor I am developing, It will be very
> I mean very user friednly to use two edit parts for the same model and
> this parts to be in the same parent.
> So, for this custom case I am sure that having "one model - many edit
> parts" is a very good solution...
>
> CL [dnoyeb] Gilbert wrote:
>
>> kiril mitov wrote:
>
>>> Hi all,
>>> Maybe this problem has been discused before but I just could not find
>>> the solution of my problem in the previous newsgroup posts and in
>>> bugs.eclipse.org...
>>>
>>> I have a class called VariablesHolder with tree method getInVariables(),
>>> getOutVariables(), and getInOutVariables().
>>> The edit part for the VariablesHolder is called VariablesHolderEditPart.
>>> The method getModelChildren() of the VariablesHolderEditPart looks like
>>> this:
>>>
>>> protected List getModelChildren() {
>>> List list = new ArrayList();
>>> list.addAll(getHolder().getInVariables());
>>> list.addAll(getHolder().getOutVariables());
>>> list.addAll(getHolder().getInOutVariables();
>>> return list;
>>> }
>>> Every variable is presented with an edit part. And everything works
>>> fine.
>>>
>>> I encountered a problem when I tried to present the inout variables with
>>> two edit part. So every inout variable must have two edit parts.
>>> It should be possible to achive such functionality.
>>>
>>> So to create two edit parts I looked in the
>>> AbstractEditPart::refreshChildren and decide to override this method so
>>> that when I encounter an inout variable I will create two edit parts.
>>> But then I noticed the following sentence in the documentation of the
>>> method:
>>> "* This method should <em>not</em> be overridden."
>>>
>>> So my question is how can I achive the functionality of "one model may
>>> parts" when I should not override this method?
>>>
>>> Ofcourse the documentation of the method do not stop me from overriding
>>> it, but is there a way to solve my problem without overriding the
>>> refrehsChildren method?
>>>
>>> And if I am to override refreshChildren() what consequence should I
>>> expect? Anything special?
>>>
>>> Thank you in advance...
>
>
>> What are you trying to achieve by having 2 edit parts use 1 model within
>> the
>> same parent edit part? Perhaps there is another, better way to achieve
>> this.
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
|
|
|
| Re: "One model - many edit parts" problem! [message #218530 is a reply to message #218444] |
Mon, 26 June 2006 14:57 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Having two editparts for the same model is possible. Can you be more
specific about the problem you are having. Perhaps screenshots or mockups
would help.
"kiril mitov" <kiril_mitov@abv.bg> wrote in message
news:1373761bb88a462728c4a8f64bdc2d63$1@www.eclipse.org...
> Hi all,
> Maybe this problem has been discused before but I just could not find the
> solution of my problem in the previous newsgroup posts and in
> bugs.eclipse.org...
>
> I have a class called VariablesHolder with tree method getInVariables(),
> getOutVariables(), and getInOutVariables().
> The edit part for the VariablesHolder is called VariablesHolderEditPart.
> The method getModelChildren() of the VariablesHolderEditPart looks like
> this:
>
> protected List getModelChildren() {
> List list = new ArrayList();
> list.addAll(getHolder().getInVariables());
> list.addAll(getHolder().getOutVariables());
> list.addAll(getHolder().getInOutVariables();
> return list;
> }
> Every variable is presented with an edit part. And everything works fine.
>
> I encountered a problem when I tried to present the inout variables with
> two edit part. So every inout variable must have two edit parts.
> It should be possible to achive such functionality.
> So to create two edit parts I looked in the
> AbstractEditPart::refreshChildren and decide to override this method so
> that when I encounter an inout variable I will create two edit parts.
> But then I noticed the following sentence in the documentation of the
> method: "* This method should <em>not</em> be overridden."
>
> So my question is how can I achive the functionality of "one model may
> parts" when I should not override this method?
>
> Ofcourse the documentation of the method do not stop me from overriding
> it, but is there a way to solve my problem without overriding the
> refrehsChildren method?
>
> And if I am to override refreshChildren() what consequence should I
> expect? Anything special?
>
> Thank you in advance...
>
>
>
>
|
|
| |
| Re: "One model - many edit parts" problem! [message #218626 is a reply to message #218515] |
Tue, 27 June 2006 16:13 |
kiril mitov
Messages: 128
Registered: July 2009 |
Senior Member |
|
|
Thanks...
Ofcourse this have always been a solution. And I have even try it, but
having the "one model - many parts" sounds much more as the solution for
me, so maybe I will first try to implemented it this way and if I have
many problems I will implemented it the way you have proposed.
And here I come to the question - If I override the refreshChildren()
method would the behaviour of certain classes change in a dramatic way
and would this cause any "hide" problems? Are there any basic guidelines
that I should consider when overriding the refreshChildren method?
Thanks in advance...
CL [dnoyeb] Gilbert wrote:
> The most GEF centric way would be to return a single edit part, and that
> edit part will have two children. One child will be the in and one will be
> the out. The single edit part you return can have a free form figure just
> like the other containers often do. So it is not seen but its two children
> are.
>
> You really can not have two edit parts with the same model since that is not
> gefs architecture. There is a map that maps models to edit parts and it
> would not work well if you did that.
>
> The other alternative is to create two mini models for each in-out model.
> One representing in and one representing out. So when the parent is asked
> for all children, you return the ins and outs, and then these sub/mini
> models. Which can be simple wrappers around the actual model with an added
> method
>
> class InModel implements MainModel {
> public boolean isIn(){ return true;}
> }
> class OutModel implements MainModel {
> public boolean isIn(){return false;}
> }
>
> Its probably adviseable to hold onto the instances and return the same ones
> each time else GEF may dump and recreate the editparts when it does not
> need to.
>
>
> The models you give to your views do not have to match exactly your true
> models.
>
>
>
> CL
>
>
> kiril mitov wrote:
>
>
>>Thanks for the reply Gilbert...
>>Whell, as I said I have in, out, and inout variables.
>>A variable of type IN is represented by one edit part that shows some
>>information for the variable. The same applies for an OUT variable.
>>But an INOUT variable must be represented with two edit parts - one that
>>shows the "in" information for the inout variable and one that shows the
>>"out" information for the inout variable.
>>
>>From my point of view, and for the editor I am developing, It will be very
>>I mean very user friednly to use two edit parts for the same model and
>>this parts to be in the same parent.
>>So, for this custom case I am sure that having "one model - many edit
>>parts" is a very good solution...
>>
>>CL [dnoyeb] Gilbert wrote:
>>
>>
>>>kiril mitov wrote:
>>
>>>>Hi all,
>>>>Maybe this problem has been discused before but I just could not find
>>>>the solution of my problem in the previous newsgroup posts and in
>>>>bugs.eclipse.org...
>>>>
>>>>I have a class called VariablesHolder with tree method getInVariables(),
>>>>getOutVariables(), and getInOutVariables().
>>>>The edit part for the VariablesHolder is called VariablesHolderEditPart.
>>>>The method getModelChildren() of the VariablesHolderEditPart looks like
>>>>this:
>>>>
>>>>protected List getModelChildren() {
>>>>List list = new ArrayList();
>>>>list.addAll(getHolder().getInVariables());
>>>> list.addAll(getHolder().getOutVariables());
>>>> list.addAll(getHolder().getInOutVariables();
>>>>return list;
>>>>}
>>>>Every variable is presented with an edit part. And everything works
>>>>fine.
>>>>
>>>>I encountered a problem when I tried to present the inout variables with
>>>>two edit part. So every inout variable must have two edit parts.
>>>>It should be possible to achive such functionality.
>>>>
>>>>So to create two edit parts I looked in the
>>>>AbstractEditPart::refreshChildren and decide to override this method so
>>>>that when I encounter an inout variable I will create two edit parts.
>>>>But then I noticed the following sentence in the documentation of the
>>>>method:
>>>>"* This method should <em>not</em> be overridden."
>>>>
>>>>So my question is how can I achive the functionality of "one model may
>>>>parts" when I should not override this method?
>>>>
>>>>Ofcourse the documentation of the method do not stop me from overriding
>>>>it, but is there a way to solve my problem without overriding the
>>>>refrehsChildren method?
>>>>
>>>>And if I am to override refreshChildren() what consequence should I
>>>>expect? Anything special?
>>>>
>>>>Thank you in advance...
>>
>>
>>>What are you trying to achieve by having 2 edit parts use 1 model within
>>>the
>>>same parent edit part? Perhaps there is another, better way to achieve
>>>this.
>
>
>
>
|
|
|
| Re: "One model - many edit parts" problem! [message #218651 is a reply to message #218626] |
Tue, 27 June 2006 18:13 |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
I wish I knew. My advise is still the new wrapper class with the tacked on
'boolean isIN()' method. Less pain in the long run.
one model - many parts within the same parent edit part is going to go over
poorly with GEF. If you really want to do it I think you are on the right
path in overriding refreshChildren. I don't think you will see any side
effects right away. They will only come as you begin to implement more
features. For instance, I suppose you are not using an EditPart Factory in
your editor since you must be creating the edit parts in your
refreshChildren method?
Kiril Mitov wrote:
> Thanks...
> Ofcourse this have always been a solution. And I have even try it, but
> having the "one model - many parts" sounds much more as the solution for
> me, so maybe I will first try to implemented it this way and if I have
> many problems I will implemented it the way you have proposed.
>
> And here I come to the question - If I override the refreshChildren()
> method would the behaviour of certain classes change in a dramatic way
> and would this cause any "hide" problems? Are there any basic guidelines
> that I should consider when overriding the refreshChildren method?
>
> Thanks in advance...
>
>
> CL [dnoyeb] Gilbert wrote:
>> The most GEF centric way would be to return a single edit part, and that
>> edit part will have two children. One child will be the in and one will
>> be
>> the out. The single edit part you return can have a free form figure
>> just
>> like the other containers often do. So it is not seen but its two
>> children are.
>>
>> You really can not have two edit parts with the same model since that is
>> not
>> gefs architecture. There is a map that maps models to edit parts and it
>> would not work well if you did that.
>>
>> The other alternative is to create two mini models for each in-out model.
>> One representing in and one representing out. So when the parent is
>> asked for all children, you return the ins and outs, and then these
>> sub/mini
>> models. Which can be simple wrappers around the actual model with an
>> added method
>>
>> class InModel implements MainModel {
>> public boolean isIn(){ return true;}
>> }
>> class OutModel implements MainModel {
>> public boolean isIn(){return false;}
>> }
>>
>> Its probably adviseable to hold onto the instances and return the same
>> ones each time else GEF may dump and recreate the editparts when it does
>> not need to.
>>
>>
>> The models you give to your views do not have to match exactly your true
>> models.
>>
>>
>>
>> CL
>>
>>
>> kiril mitov wrote:
>>
>>
>>>Thanks for the reply Gilbert...
>>>Whell, as I said I have in, out, and inout variables.
>>>A variable of type IN is represented by one edit part that shows some
>>>information for the variable. The same applies for an OUT variable.
>>>But an INOUT variable must be represented with two edit parts - one that
>>>shows the "in" information for the inout variable and one that shows the
>>>"out" information for the inout variable.
>>>
>>>From my point of view, and for the editor I am developing, It will be
>>>very I mean very user friednly to use two edit parts for the same model
>>>and this parts to be in the same parent.
>>>So, for this custom case I am sure that having "one model - many edit
>>>parts" is a very good solution...
>>>
>>>CL [dnoyeb] Gilbert wrote:
>>>
>>>
>>>>kiril mitov wrote:
>>>
>>>>>Hi all,
>>>>>Maybe this problem has been discused before but I just could not find
>>>>>the solution of my problem in the previous newsgroup posts and in
>>>>>bugs.eclipse.org...
>>>>>
>>>>>I have a class called VariablesHolder with tree method
>>>>>getInVariables(), getOutVariables(), and getInOutVariables().
>>>>>The edit part for the VariablesHolder is called
>>>>>VariablesHolderEditPart. The method getModelChildren() of the
>>>>>VariablesHolderEditPart looks like this:
>>>>>
>>>>>protected List getModelChildren() {
>>>>>List list = new ArrayList();
>>>>>list.addAll(getHolder().getInVariables());
>>>>> list.addAll(getHolder().getOutVariables());
>>>>> list.addAll(getHolder().getInOutVariables();
>>>>>return list;
>>>>>}
>>>>>Every variable is presented with an edit part. And everything works
>>>>>fine.
>>>>>
>>>>>I encountered a problem when I tried to present the inout variables
>>>>>with two edit part. So every inout variable must have two edit parts.
>>>>>It should be possible to achive such functionality.
>>>>>
>>>>>So to create two edit parts I looked in the
>>>>>AbstractEditPart::refreshChildren and decide to override this method so
>>>>>that when I encounter an inout variable I will create two edit parts.
>>>>>But then I noticed the following sentence in the documentation of the
>>>>>method:
>>>>>"* This method should <em>not</em> be overridden."
>>>>>
>>>>>So my question is how can I achive the functionality of "one model may
>>>>>parts" when I should not override this method?
>>>>>
>>>>>Ofcourse the documentation of the method do not stop me from overriding
>>>>>it, but is there a way to solve my problem without overriding the
>>>>>refrehsChildren method?
>>>>>
>>>>>And if I am to override refreshChildren() what consequence should I
>>>>>expect? Anything special?
>>>>>
>>>>>Thank you in advance...
>>>
>>>
>>>>What are you trying to achieve by having 2 edit parts use 1 model within
>>>>the
>>>>same parent edit part? Perhaps there is another, better way to achieve
>>>>this.
>>
>>
>>
>>
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
|
|
|
| Re: "One model - many edit parts" problem! [message #218659 is a reply to message #218651] |
Tue, 27 June 2006 18:33 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
I was thinking of just an "if" statement in the refreshChildren() method.
So if one of the modelObjects is and inout variable I will just use the
addChild() and createChild() methods twice - first for the in part and
second for the out part.
I will still use an EditPartFactory. When the factory is asked to
created an edit part based on an inout variable, it will be smart
enought to know which part to create - the in or the out part. One
approache I was thinking for was to use the context param passed to the
create method of the factory.
So when an inout variable is passed the factory checks if there is an in
part for this inout variable in this context. If there is such a part
than an out part is created. If there is no such part than an in part is
created. Here the edit part is of type VariableEditPart and has a method
isIn() that returns true or false and getTwinPart() that returns the
other part( for in part it returns the out part, and for the out it
returns the in).
So what I should do is first to remove the modelToEditPart map in the
refreshChildren() method and use a custom way to find which parts must
be reordered, added or created. Than I should make the EditPartFactory
rather smart to achive the given functionality...
In fact I have almost implemented this way.
But I still have some doubts whether this is the right solution...
Any help is appreciated...
CL [dnoyeb] Gilbert wrote:
> I wish I knew. My advise is still the new wrapper class with the tacked on
> 'boolean isIN()' method. Less pain in the long run.
>
> one model - many parts within the same parent edit part is going to go over
> poorly with GEF. If you really want to do it I think you are on the right
> path in overriding refreshChildren. I don't think you will see any side
> effects right away. They will only come as you begin to implement more
> features. For instance, I suppose you are not using an EditPart Factory in
> your editor since you must be creating the edit parts in your
> refreshChildren method?
>
>
> Kiril Mitov wrote:
>
>
>>Thanks...
>>Ofcourse this have always been a solution. And I have even try it, but
>>having the "one model - many parts" sounds much more as the solution for
>>me, so maybe I will first try to implemented it this way and if I have
>>many problems I will implemented it the way you have proposed.
>>
>>And here I come to the question - If I override the refreshChildren()
>>method would the behaviour of certain classes change in a dramatic way
>>and would this cause any "hide" problems? Are there any basic guidelines
>>that I should consider when overriding the refreshChildren method?
>>
>>Thanks in advance...
>>
>>
>>CL [dnoyeb] Gilbert wrote:
>>
>>>The most GEF centric way would be to return a single edit part, and that
>>>edit part will have two children. One child will be the in and one will
>>>be
>>>the out. The single edit part you return can have a free form figure
>>>just
>>>like the other containers often do. So it is not seen but its two
>>>children are.
>>>
>>>You really can not have two edit parts with the same model since that is
>>>not
>>>gefs architecture. There is a map that maps models to edit parts and it
>>>would not work well if you did that.
>>>
>>>The other alternative is to create two mini models for each in-out model.
>>>One representing in and one representing out. So when the parent is
>>>asked for all children, you return the ins and outs, and then these
>>>sub/mini
>>>models. Which can be simple wrappers around the actual model with an
>>>added method
>>>
>>>class InModel implements MainModel {
>>> public boolean isIn(){ return true;}
>>>}
>>>class OutModel implements MainModel {
>>> public boolean isIn(){return false;}
>>>}
>>>
>>>Its probably adviseable to hold onto the instances and return the same
>>>ones each time else GEF may dump and recreate the editparts when it does
>>>not need to.
>>>
>>>
>>>The models you give to your views do not have to match exactly your true
>>>models.
>>>
>>>
>>>
>>>CL
>>>
>>>
>>>kiril mitov wrote:
>>>
>>>
>>>
>>>>Thanks for the reply Gilbert...
>>>>Whell, as I said I have in, out, and inout variables.
>>>>A variable of type IN is represented by one edit part that shows some
>>>>information for the variable. The same applies for an OUT variable.
>>>>But an INOUT variable must be represented with two edit parts - one that
>>>>shows the "in" information for the inout variable and one that shows the
>>>>"out" information for the inout variable.
>>>>
>>>
>>>>From my point of view, and for the editor I am developing, It will be
>>>
>>>>very I mean very user friednly to use two edit parts for the same model
>>>>and this parts to be in the same parent.
>>>>So, for this custom case I am sure that having "one model - many edit
>>>>parts" is a very good solution...
>>>>
>>>>CL [dnoyeb] Gilbert wrote:
>>>>
>>>>
>>>>
>>>>>kiril mitov wrote:
>>>>
>>>>>>Hi all,
>>>>>>Maybe this problem has been discused before but I just could not find
>>>>>>the solution of my problem in the previous newsgroup posts and in
>>>>>>bugs.eclipse.org...
>>>>>>
>>>>>>I have a class called VariablesHolder with tree method
>>>>>>getInVariables(), getOutVariables(), and getInOutVariables().
>>>>>>The edit part for the VariablesHolder is called
>>>>>>VariablesHolderEditPart. The method getModelChildren() of the
>>>>>>VariablesHolderEditPart looks like this:
>>>>>>
>>>>>>protected List getModelChildren() {
>>>>>>List list = new ArrayList();
>>>>>>list.addAll(getHolder().getInVariables());
>>>>>> list.addAll(getHolder().getOutVariables());
>>>>>> list.addAll(getHolder().getInOutVariables();
>>>>>>return list;
>>>>>>}
>>>>>>Every variable is presented with an edit part. And everything works
>>>>>>fine.
>>>>>>
>>>>>>I encountered a problem when I tried to present the inout variables
>>>>>>with two edit part. So every inout variable must have two edit parts.
>>>>>>It should be possible to achive such functionality.
>>>>>>
>>>>>>So to create two edit parts I looked in the
>>>>>>AbstractEditPart::refreshChildren and decide to override this method so
>>>>>>that when I encounter an inout variable I will create two edit parts.
>>>>>>But then I noticed the following sentence in the documentation of the
>>>>>>method:
>>>>>>"* This method should <em>not</em> be overridden."
>>>>>>
>>>>>>So my question is how can I achive the functionality of "one model may
>>>>>>parts" when I should not override this method?
>>>>>>
>>>>>>Ofcourse the documentation of the method do not stop me from overriding
>>>>>>it, but is there a way to solve my problem without overriding the
>>>>>>refrehsChildren method?
>>>>>>
>>>>>>And if I am to override refreshChildren() what consequence should I
>>>>>>expect? Anything special?
>>>>>>
>>>>>>Thank you in advance...
>>>>
>>>>
>>>>>What are you trying to achieve by having 2 edit parts use 1 model within
>>>>>the
>>>>>same parent edit part? Perhaps there is another, better way to achieve
>>>>>this.
>>>
>>>
>>>
>>>
>
|
|
|
| Re: "One model - many edit parts" problem! [message #218675 is a reply to message #218659] |
Tue, 27 June 2006 19:39 |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
user@domain.invalid wrote:
> I was thinking of just an "if" statement in the refreshChildren() method.
> So if one of the modelObjects is and inout variable I will just use the
> addChild() and createChild() methods twice - first for the in part and
> second for the out part.
> I will still use an EditPartFactory. When the factory is asked to
> created an edit part based on an inout variable, it will be smart
> enought to know which part to create - the in or the out part. One
> approache I was thinking for was to use the context param passed to the
> create method of the factory.
> So when an inout variable is passed the factory checks if there is an in
> part for this inout variable in this context. If there is such a part
> than an out part is created. If there is no such part than an in part is
> created. Here the edit part is of type VariableEditPart and has a method
> isIn() that returns true or false and getTwinPart() that returns the
> other part( for in part it returns the out part, and for the out it
> returns the in).
>
> So what I should do is first to remove the modelToEditPart map in the
> refreshChildren() method and use a custom way to find which parts must
> be reordered, added or created. Than I should make the EditPartFactory
> rather smart to achive the given functionality...
> In fact I have almost implemented this way.
>
> But I still have some doubts whether this is the right solution...
> Any help is appreciated...
>
Let me get this right;
1. add an if to refreshChildren
2. add an if to EditPartFactory
3. create artificial connection between VariableEditPart instances through
getTwinPart.
4. remove the modelToEditPart map.
5. create custom way to order add and create editparts?
vs.
1. Create wrapper around true model adding isIn() method.
2. children() method returns one wrapper model with isIn true and one
wrapper with isIn false in place of original model.
3. VariableEditPart asks model isIn() to know which figure to create (in or
out.)
class DecoratorModel {
private YourModel model;
private boolean in;
ChildModel(YourModel model, boolean in){
this.model = model;
this.in=in;
}
public boolean isIn(){
return in;
}
//forward all calls to YourModel
}
protected List getModelChildren() {
ArrayList list = new ArrayList();
list.addAll(getHolder().getInVariables());
list.addAll(getHolder().getOutVariables());
for(Iterator It =
getHolder().getInOutVariables().iterator();it.hasNext();){
YourModel model = (YourModel)it.next();
list.add(new DecoratorModel(model,true));
list.add(new DecoratorModel(model,false));
}
return list;
}
You say this was always an option. I wonder what about it bothers you, or
what you are not telling us about your requirements?
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
|
|
|
| Re: "One model - many edit parts" problem! [message #218683 is a reply to message #218675] |
Tue, 27 June 2006 21:17 |
kiril mitov
Messages: 128
Registered: July 2009 |
Senior Member |
|
|
CL [dnoyeb] Gilbert wrote:
> user@domain.invalid wrote:
>
>
>>I was thinking of just an "if" statement in the refreshChildren() method.
>>So if one of the modelObjects is and inout variable I will just use the
>>addChild() and createChild() methods twice - first for the in part and
>>second for the out part.
>>I will still use an EditPartFactory. When the factory is asked to
>>created an edit part based on an inout variable, it will be smart
>>enought to know which part to create - the in or the out part. One
>>approache I was thinking for was to use the context param passed to the
>>create method of the factory.
>>So when an inout variable is passed the factory checks if there is an in
>>part for this inout variable in this context. If there is such a part
>>than an out part is created. If there is no such part than an in part is
>>created. Here the edit part is of type VariableEditPart and has a method
>>isIn() that returns true or false and getTwinPart() that returns the
>>other part( for in part it returns the out part, and for the out it
>>returns the in).
>>
>>So what I should do is first to remove the modelToEditPart map in the
>>refreshChildren() method and use a custom way to find which parts must
>>be reordered, added or created. Than I should make the EditPartFactory
>>rather smart to achive the given functionality...
>>In fact I have almost implemented this way.
>>
>>But I still have some doubts whether this is the right solution...
>>Any help is appreciated...
>>
>
>
> Let me get this right;
> 1. add an if to refreshChildren
> 2. add an if to EditPartFactory
> 3. create artificial connection between VariableEditPart instances through
> getTwinPart.
> 4. remove the modelToEditPart map.
> 5. create custom way to order add and create editparts?
>
>
> vs.
> 1. Create wrapper around true model adding isIn() method.
> 2. children() method returns one wrapper model with isIn true and one
> wrapper with isIn false in place of original model.
> 3. VariableEditPart asks model isIn() to know which figure to create (in or
> out.)
>
> class DecoratorModel {
> private YourModel model;
> private boolean in;
> ChildModel(YourModel model, boolean in){
> this.model = model;
> this.in=in;
> }
> public boolean isIn(){
> return in;
> }
> //forward all calls to YourModel
> }
>
>
> protected List getModelChildren() {
> ArrayList list = new ArrayList();
> list.addAll(getHolder().getInVariables());
> list.addAll(getHolder().getOutVariables());
> for(Iterator It =
> getHolder().getInOutVariables().iterator();it.hasNext();){
> YourModel model = (YourModel)it.next();
> list.add(new DecoratorModel(model,true));
> list.add(new DecoratorModel(model,false));
> }
> return list;
> }
>
> You say this was always an option. I wonder what about it bothers you, or
> what you are not telling us about your requirements?
>
>
Dont get me wrong CL [dnoyeb] Gilbert, there isn`t something I am not
telling. Something I am hiding.
But when considering a Model-View-Controller architecture like GEF I
have always had the feeling that there should be no one to one mapping
between the model and the controller (in this case the edit part). Thats
way it bothers me. I wasn`t feeling it this way...
One of my GEF editors used a "one model - many parts" mapping but with
parts in different parents. There were no problems. Now when I came to
creating the parts in the same parent things got more, lets say "complex".
If creating the DecoratorModel objects is the GEF way, then let it be
the GEF way. No argue :)
Thanks...
|
|
|
Goto Forum:
Current Time: Tue Apr 23 17:48:55 GMT 2024
Powered by FUDForum. Page generated in 0.04051 seconds |
] 
Search
Help
Register
Login
Home
