Home » Eclipse Projects » GEF » design pattern for representation attributes not in the model
| design pattern for representation attributes not in the model [message #65019] |
Mon, 17 February 2003 17:38  |
Eclipse User |
|
|
|
Originally posted by: john-mason.shackelford.pearson.com
My GEF editor attempts to represent items specified in an xml
configuration file as nodes. The location of each node in the editor
does not represent data in the xml file and is therefore not part of my
model. However, I do want to save layout information into a seperate
optional file as a convenience to the user.
So far I am thinking that I need a class to handle representation-only
attributes. Each EditPart would keep a reference to a
"representation-only" object while the model would no nothing about it.
Since I do want to be able to persist these representation-only
attributes in a seperate file, I do need a way to collect this
information--perhaps by iterating through all the children of the
Contents and calling a getter.
Perhaps there is a better way to do this. Design suggestions? Am I
neglecting parts of the API I could be using to facilitate this?
--
John-Mason Shackelford
Software Developer
Pearson Educational Measurement - eMeasurement Group
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://etest.ncspearson.com
|
|
|
| Re: design pattern for representation attributes not in the model [message #65027 is a reply to message #65019] |
Mon, 17 February 2003 18:23  |
 Eric Suen
Messages: 94
Registered: July 2009 |
Member |
|
|
Hi,
Maybe you can try use EMF(www.eclipse.org/emf) as you model framework,
I write an eclipse plug-in for Torque(db.apache.org/torque). My editor use
two
file as input, see attachments, turbine.torque has the information of the
database struct,
and turbin.dataset hold the information of the diagram and the relationship
of the
database model! use EMF, handle cross document references is easy!
Regards,
Eric
"John-Mason P. Shackelford" <john-mason.shackelford@pearson.com>
??????:3E511E23.4070204@pearson.com...
> My GEF editor attempts to represent items specified in an xml
> configuration file as nodes. The location of each node in the editor
> does not represent data in the xml file and is therefore not part of my
> model. However, I do want to save layout information into a seperate
> optional file as a convenience to the user.
>
> So far I am thinking that I need a class to handle representation-only
> attributes. Each EditPart would keep a reference to a
> "representation-only" object while the model would no nothing about it.
> Since I do want to be able to persist these representation-only
> attributes in a seperate file, I do need a way to collect this
> information--perhaps by iterating through all the children of the
> Contents and calling a getter.
>
> Perhaps there is a better way to do this. Design suggestions? Am I
> neglecting parts of the API I could be using to facilitate this?
>
> --
>
> John-Mason Shackelford
>
> Software Developer
> Pearson Educational Measurement - eMeasurement Group
>
> 2510 North Dodge St.
> Iowa City, IA 52245
> ph. 319-354-9200x6214
> john-mason.shackelford@pearson.com
> http://etest.ncspearson.com
>
|
|
|
| Re: design pattern for representation attributes not in the model [message #65118 is a reply to message #65027] |
Mon, 17 February 2003 20:05 |
| Eclipse User |
|
|
|
Originally posted by: oro7d3.netscape.net
Eric,
I am interested in how to combine the use of EMF and GEF.
There is a model (M of the MVC pattern in GEF) in GEF, are you saying to
replace that with a EMF model? If yes, how?
How can I make the model persistent? Currently GEF uses serialization, but I
run into compbability problem everything I make changes to the Model. will
EMF help me?
I would like to learn how you did that? Where you start? The logic Editor
example give me a good start about using GEF in my plugin, but there is no
such thing for EMF and certain no example to use EMF and GEF combine.
Thanks for any help.
"Eric Suen" <eric_suen_cn@hotmail.com> wrote in message
news:b2r7i2$9td$1@rogue.oti.com...
> Hi,
>
> Maybe you can try use EMF(www.eclipse.org/emf) as you model framework,
> I write an eclipse plug-in for Torque(db.apache.org/torque). My editor use
> two
> file as input, see attachments, turbine.torque has the information of the
> database struct,
> and turbin.dataset hold the information of the diagram and the
relationship
> of the
> database model! use EMF, handle cross document references is easy!
>
> Regards,
>
> Eric
>
> "John-Mason P. Shackelford" <john-mason.shackelford@pearson.com>
> ??????:3E511E23.4070204@pearson.com...
> > My GEF editor attempts to represent items specified in an xml
> > configuration file as nodes. The location of each node in the editor
> > does not represent data in the xml file and is therefore not part of my
> > model. However, I do want to save layout information into a seperate
> > optional file as a convenience to the user.
> >
> > So far I am thinking that I need a class to handle representation-only
> > attributes. Each EditPart would keep a reference to a
> > "representation-only" object while the model would no nothing about it.
> > Since I do want to be able to persist these representation-only
> > attributes in a seperate file, I do need a way to collect this
> > information--perhaps by iterating through all the children of the
> > Contents and calling a getter.
> >
> > Perhaps there is a better way to do this. Design suggestions? Am I
> > neglecting parts of the API I could be using to facilitate this?
> >
> > --
> >
> > John-Mason Shackelford
> >
> > Software Developer
> > Pearson Educational Measurement - eMeasurement Group
> >
> > 2510 North Dodge St.
> > Iowa City, IA 52245
> > ph. 319-354-9200x6214
> > john-mason.shackelford@pearson.com
> > http://etest.ncspearson.com
> >
>
>
>
|
|
|
| Re: design pattern for representation attributes not in the model [message #65141 is a reply to message #65019] |
Mon, 17 February 2003 18:45 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
You application sounds like:
A) "The User is editing a business model as a diagram". Where is "business
model" is the "real" information in you xml configuration file, and the
diagram is just a way to show that information. Also, the user is editing
the *entire* model, so your diagram shows everything from that xml file at
once. In this type of application, sometimes it makes sense to use
annotation (i.e. location) to your model, and possibly store those
annotations in a separate file. You need some way of mapping your nodes to
their annotations. The primary model is your business model.
But it could be:
B) "The user is editing a diagram of a business model". Examples include
Rational Rose. There is an underlying business model like before, but the
purpose of the diagram is to show a portion of a business model for
illustrational purposes. Also, the diagram can include elements that are
not in the business model, such as notes. Also, the same business object
may be viewed in mulitple locations. In this application, a common approach
is to make the diagram's model the primary model that GEF knows about. So in
your case, you would have a diagram, and that diagram would consist of
NodeViews. Again, you might persist those objects in a separate file. The
node views would point directly to the node they are a view for.
Since GEF can be used for either types of application, there is currently
nothing to help you make one or the other. These are model problems, and
GEF is supposed to be model neutral.
"John-Mason P. Shackelford" <john-mason.shackelford@pearson.com> wrote in
message news:3E511E23.4070204@pearson.com...
> My GEF editor attempts to represent items specified in an xml
> configuration file as nodes. The location of each node in the editor
> does not represent data in the xml file and is therefore not part of my
> model. However, I do want to save layout information into a seperate
> optional file as a convenience to the user.
>
> So far I am thinking that I need a class to handle representation-only
> attributes. Each EditPart would keep a reference to a
> "representation-only" object while the model would no nothing about it.
> Since I do want to be able to persist these representation-only
> attributes in a seperate file, I do need a way to collect this
> information--perhaps by iterating through all the children of the
> Contents and calling a getter.
>
> Perhaps there is a better way to do this. Design suggestions? Am I
> neglecting parts of the API I could be using to facilitate this?
>
> --
>
> John-Mason Shackelford
>
> Software Developer
> Pearson Educational Measurement - eMeasurement Group
>
> 2510 North Dodge St.
> Iowa City, IA 52245
> ph. 319-354-9200x6214
> john-mason.shackelford@pearson.com
> http://etest.ncspearson.com
>
|
|
| |
| Re: design pattern for representation attributes not in the model [message #65243 is a reply to message #65118] |
Tue, 18 February 2003 04:58 |
Eric Suen
Messages: 94
Registered: July 2009 |
Member |
|
|
> I am interested in how to combine the use of EMF and GEF.
> There is a model (M of the MVC pattern in GEF) in GEF, are you saying to
> replace that with a EMF model? If yes, how?
I think GEF is focus on Graphical, not on model, and the Logic example tell
you how to use GEF, not the tutorial of design pattern!
> How can I make the model persistent? Currently GEF uses serialization, but
I
> run into compbability problem everything I make changes to the Model. will
> EMF help me?
Yes, The default implementation of Resource is XMIResourceImpl, which
results in
serialization as XMI documents. If you wish to serialize in some format
other than
the default XMI format, you can provide your own implementation of Resource.
> I would like to learn how you did that? Where you start? The logic Editor
> example give me a good start about using GEF in my plugin, but there is no
> such thing for EMF and certain no example to use EMF and GEF combine.
My English is poor, It is not easy for me to explain this! Maybe next month,
I
will upload this plug-in to sourceforge.net, I hope it will help you a
little!
> Thanks for any help.
>
>
|
|
|
| Re: design pattern for representation attributes not in the model [message #65306 is a reply to message #65141] |
Tue, 18 February 2003 15:11 |
| Eclipse User |
|
|
|
Originally posted by: john-mason.shackelford.pearson.com
Randy,
I believe my application is a case of A. "The User is editing a business
model as a diagram" but quite frankly it would be much easier to write
as B. It wouldn't take much effort to split out attributes I want to
persist as the business model from those I want to persist as
annotations, but keeping track of essentially two models is proving to
be rather tricky. If things don't go well today, I'll just scrap it and
start over with the B. approach.
Thanks for your input on both questions.
--
John-Mason Shackelford
Software Developer
Pearson Educational Measurement - eMeasurement Group
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://etest.ncspearson.com
|
|
|
| Re: design pattern for representation attributes not in the model [message #65326 is a reply to message #65306] |
Tue, 18 February 2003 15:19 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
B is still two models. A NodeView points to a Node in the business model.
The difference is that the "visual" data is used to build the structure of
the diagram instead of the business data. Are you saying you are just going
to merge the two sets of properties into one model?
"John-Mason P. Shackelford" <john-mason.shackelford@pearson.com> wrote in
message news:3E524D39.1070604@pearson.com...
> Randy,
>
> I believe my application is a case of A. "The User is editing a business
> model as a diagram" but quite frankly it would be much easier to write
> as B. It wouldn't take much effort to split out attributes I want to
> persist as the business model from those I want to persist as
> annotations, but keeping track of essentially two models is proving to
> be rather tricky. If things don't go well today, I'll just scrap it and
> start over with the B. approach.
>
> Thanks for your input on both questions.
> --
>
> John-Mason Shackelford
>
> Software Developer
> Pearson Educational Measurement - eMeasurement Group
>
> 2510 North Dodge St.
> Iowa City, IA 52245
> ph. 319-354-9200x6214
> john-mason.shackelford@pearson.com
> http://etest.ncspearson.com
>
|
|
|
| Re: design pattern for representation attributes not in the model [message #65347 is a reply to message #65326] |
Tue, 18 February 2003 15:48 |
| Eclipse User |
|
|
|
Originally posted by: john-mason.shackelford.pearson.com
Randy,
> B is still two models.
Ah, yes. so I suppose I was threatening to do C. merge the models.
I am going to give it another day before I give up.
Yesterday I was struggling to come up with a clean design for
maintaining both. Each EditPart will have to know about both models so I
suppose I could add an extra setter for the annotations and then call
them from the GraphicalPartFactory. I suppose the ContentsEditPart could
be handed a collection of annotations from the Editor (on loading the
annotations resource) and could pass it to the GraphicalPartFactory at
that point, but it just seems like I am making a mess. If I do use two
models I suppose I need to accept the fact that this design decision is
going to ripple though quite a bit of code.
You mentioned that Rational Rose does maintain two models. Can you tell
me something about how they do it--or how you would do it?
--
John-Mason Shackelford
Software Developer
Pearson Educational Measurement - eMeasurement Group
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://etest.ncspearson.com
|
|
|
Goto Forum:
Current Time: Fri Dec 27 02:55:03 GMT 2024
Powered by FUDForum. Page generated in 0.25577 seconds |
] 
Search
Help
Register
Login
Home
