Home » Modeling » EMF » How to implement nodes with variable number of properties
| |
| Re: How to implement nodes with variable number of properties [message #424346 is a reply to message #424334] |
Fri, 24 October 2008 07:06   |
 Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for the reply.
Sorry for giving very less information on my previous post.
Please find the comments below.
Ed Merks wrote:
> Asha,
> Comments below.
> Asha R wrote:
>> Hi,
>>
>> I have a model which represents a set of hardware devices. Each device
>> may have different properties and different number of properties.
>>
>> Is there any way to handle such properties using properties view
>> without creating an intermediate class that takes care of these
>> variable properties.
> I'm not sure how you model is defined. On which class are these
> properties defined?
> In theory you could use an XML Schema approach and define each complex
> type to have a wildcard that allows any element from its global elements
> to appear. You'd still have to specialize the collection of property
> descriptors created for each class, since wildcards are open ended and
> EMF won't compute the allowable set as individual properties. It also
> wouldn't help restriction which type of device allowed which specific
> properties.
I did not get exactly what you mean by this. But, I would like to know
about it in more detail. I would also like to explain our approach. Here
we have a set of devices which should be handled with a expandable tree.
We should be able to add a device as a node of the tree. And the
definition of the device comes from an xmi file. So, my device element
class should be able to handle the properties of these devices. Each
device may have it's own property names and may vary based on the scenario
also, for example based on the kind of bus it is connected to, it may have
to handle something specific to the bus. Also a bus can be a device.
In this scenario, what we are trying to do is to have a property class and
possibly a attribute class and have a list of attributes in the property
class and a list of properties in the device class. This way we can
generate an xmi for a set of devices easily. But the problem is when we
define the properties this way, I am not sure how to handle the properties
with the property editor. How can I tie up the property editor to handle
these properties which are inside the property class and the attribute
classes. There must be simple solution also, which I don't know. Or else
may be I have to see whether I can generate the property descriptors
dynamically inside the class. But as we are planning to use emf to
generate the code, I would't be able to use this approach it seems.
So, I just wanted to know is there any other construct in emf that defines
how to handle the variable properties.
> Perhaps an alternative is to define a single device class with all
> possible properties along with an enum to specify each specific device.
> You'd then need to manage filtering the properties based on the enum.
The problem, I got to know, here is we can't even generalize it to some
minimum extent, except name and type probably :-), and have the
specialized classes for variations. As, the number of devices can grow and
they may have very different properties it will require to add a
specialized class for each such device and keep building the platform each
time. And the number of addition can grow in terms 10s and 50s or 100!
> The simplest seems to be to just model it the normal way (a hierarchy
> with properties on the appropriate classes) but there must be some
> reason for not wanting to do that. Why not do it that way?
>>
>> Sorry, if I am posting this question in a wrong forum.
>>
>> Thank you,
>>
>> Asha R.
>>
|
|
|
| Re: How to implement nodes with variable number of properties [message #424347 is a reply to message #424346] |
Fri, 24 October 2008 08:46 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020105050803010900040809
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Asha,
Comments below.
Asha R wrote:
> Hi Ed,
>
> Thanks for the reply.
> Sorry for giving very less information on my previous post.
> Please find the comments below.
>
> Ed Merks wrote:
>
>> Asha,
>
>> Comments below.
>
>
>> Asha R wrote:
>>> Hi,
>>>
>>> I have a model which represents a set of hardware devices. Each
>>> device may have different properties and different number of
>>> properties.
>>>
>>> Is there any way to handle such properties using properties view
>>> without creating an intermediate class that takes care of these
>>> variable properties.
>> I'm not sure how you model is defined. On which class are these
>> properties defined?
>
>> In theory you could use an XML Schema approach and define each
>> complex type to have a wildcard that allows any element from its
>> global elements to appear. You'd still have to specialize the
>> collection of property descriptors created for each class, since
>> wildcards are open ended and EMF won't compute the allowable set as
>> individual properties. It also wouldn't help restriction which type
>> of device allowed which specific properties.
>
> I did not get exactly what you mean by this. But, I would like to know
> about it in more detail.
Do you know about wildcards in XML Schema? This provides some background.
Binding XML to Java
< http://www.theserverside.com/tt/articles/article.tss?l=Bindi ngXMLJava>
> I would also like to explain our approach. Here we have a set of
> devices which should be handled with a expandable tree. We should be
> able to add a device as a node of the tree. And the definition of the
> device comes from an xmi file. So, my device element class should be
> able to handle the properties of these devices. Each device may have
> it's own property names and may vary based on the scenario also, for
> example based on the kind of bus it is connected to, it may have to
> handle something specific to the bus. Also a bus can be a device.
It sounds not so much different from this type of approach where the
definition of the new device is effectively just another Ecore model
that extends the base device model:
Creating Children You Didn't Know Existed
< http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html>
>
> In this scenario, what we are trying to do is to have a property class
> and possibly a attribute class and have a list of attributes in the
> property class and a list of properties in the device class.
I'm not sure I understand property verses attribute.
> This way we can generate an xmi for a set of devices easily. But the
> problem is when we define the properties this way, I am not sure how
> to handle the properties with the property editor.
In the end, the properties view will display exactly the property
descriptors that you compute in the item provider for the instance object...
> How can I tie up the property editor to handle these properties which
> are inside the property class and the attribute classes. There must be
> simple solution also, which I don't know. Or else may be I have to see
> whether I can generate the property descriptors dynamically inside the
> class.
Yes, you can always generated property descriptors as needed in the item
provider code. MappingItemProvider and TreeItemProvider show examples
of trickier ways to generate property descriptors.
> But as we are planning to use emf to generate the code, I would't be
> able to use this approach it seems.
You'd have the item provider control the properties, not the model itself.
> So, I just wanted to know is there any other construct in emf that
> defines how to handle the variable properties.
It also sounds like your "device description" could simply be an Ecore
model with a specialized EClass for that device...
>
>> Perhaps an alternative is to define a single device class with all
>> possible properties along with an enum to specify each specific
>> device. You'd then need to manage filtering the properties based on
>> the enum.
>
> The problem, I got to know, here is we can't even generalize it to
> some minimum extent, except name and type probably :-), and have the
> specialized classes for variations. As, the number of devices can grow
> and they may have very different properties it will require to add a
> specialized class for each such device and keep building the platform
> each time. And the number of addition can grow in terms 10s and 50s or
> 100!
The simplest approach seems to me to define an EClass for each. Each
specialized could be in a separate package and extend from a base
Device EClass in the root package or specialize some other
already-specialized class deeper in the hierarchy. Just be sure to
follow the steps in that blog above to make your base package's item
providers extensible and your derived package's item providers extenders.
>
>> The simplest seems to be to just model it the normal way (a hierarchy
>> with properties on the appropriate classes) but there must be some
>> reason for not wanting to do that. Why not do it that way?
>>>
>>> Sorry, if I am posting this question in a wrong forum.
>>>
>>> Thank you,
>>>
>>> Asha R.
>>>
>
--------------020105050803010900040809
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Asha,<br>
<br>
Comments below.<br>
<br>
<br>
Asha R wrote:
<blockquote
cite="mid:ed9a9ecdf0937e6c38aa08d018e15e6b$1@www.eclipse.org"
type="cite">Hi Ed,
<br>
<br>
Thanks for the reply.
<br>
Sorry for giving very less information on my previous post.
<br>
Please find the comments below.
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">Asha,
<br>
</blockquote>
<br>
<blockquote type="cite">Comments below.
<br>
</blockquote>
<br>
<br>
<blockquote type="cite">Asha R wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I have a model which represents a set of hardware devices. Each device
may have different properties and different number of properties.
<br>
<br>
Is there any way to handle such properties using properties view
without creating an intermediate class that takes care of these
variable properties.
<br>
</blockquote>
I'm not sure how you model is defined.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: How to implement nodes with variable number of properties [message #424869 is a reply to message #424347] |
Fri, 07 November 2008 13:42 |
Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Ed,
I have gone through the example you pointed to on your blog and felt it's
not something we wanted to do.
Later, each day by day my requirement is taking a new shape (when I
consider about the implementation) when I think about it. Probably I am
terribly confused!
So, I hope the only superman who can save me by answering my questions
would be probably the EMF team lead himself... :)))). Probably they are
very simple questions for him. Please don't mind. :-).
Currently I would like to put my requirement in my simplest possible terms.
I have a class say, Device in my model. It can have a list of, say another
class, Property which has an attribute property_name. When I select the
Device node my properties editor should display these property_names as
the properties of this device. Of course, they can be handled by
ItemProviders, I understand.
But, during the time I am generating code for this model I don't know how
many number of property_names I am going to have in my Device, as they are
not known at this point of time. So, now I have to read from an XML file
that documents the Device's property_names and populate this model with
those property_names as the properties of the device!!!
When I have already generated my model and editor for the same, I wonder
how can I populate these new property_names in the Device class instance?
Because even when you are handling them with the ItemProviders, the
ItemProvider would query a model class that has all these details! As this
class is already generated how can I fetch these new values?
If I write some my own code here, to fetch the values from XML, then,
where I will save them in the model?
As, one more reply to this thread says, I guess reading from XML and
generating a model class on the fly and compiling would help. But, that
should be so programmatic that end user should not know, that the model
and editor got re-generated based on the XML input. I doubt at the
feasibility of this task.
Thank you,
Asha R.
|
|
|
| Re: How to implement nodes with variable number of properties [message #424870 is a reply to message #424869] |
Fri, 07 November 2008 14:16 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Asha,
Comments below.
Asha R wrote:
> Hi Ed,
>
> I have gone through the example you pointed to on your blog and felt
> it's not something we wanted to do.
>
> Later, each day by day my requirement is taking a new shape (when I
> consider about the implementation) when I think about it. Probably I
> am terribly confused!
>
> So, I hope the only superman who can save me by answering my questions
> would be probably the EMF team lead himself... :)))). Probably they
> are very simple questions for him. Please don't mind. :-).
Flattery will get you everywhere? :-P
>
> Currently I would like to put my requirement in my simplest possible
> terms.
>
> I have a class say, Device in my model. It can have a list of, say
> another class, Property which has an attribute property_name. When I
> select the Device node my properties editor should display these
> property_names as the properties of this device. Of course, they can
> be handled by ItemProviders, I understand.
So you literally mean to model it as a list of Property instances where
a Property is like a name/value pair... Are the values always strings?
You can look at how TreeNodeItemProvider.getPropertyDescriptors creates
a property descriptor for each property of the EObject referenced by
it's data field.
>
> But, during the time I am generating code for this model I don't know
> how many number of property_names I am going to have in my Device, as
> they are not known at this point of time.
You'll just know you can have a list...
> So, now I have to read from an XML file that documents the Device's
> property_names and populate this model with those property_names as
> the properties of the device!!!
So you're not statically going to have different "types" of devices but
rather configure them based on some data somewhere... How will you know
the association between any given Device instance and the information
about what properties it's allowed to have?
>
> When I have already generated my model and editor for the same, I
> wonder how can I populate these new property_names in the Device class
> instance?
EMF's classes have much the same limitations as Java classes in that you
can't change them once there are instances and you can't change them at
all if there is a generated Java implementation for them because you
can't change the Java class itself.
> Because even when you are handling them with the ItemProviders, the
> ItemProvider would query a model class that has all these details!
Yes, but if you have a list of Property children you could make their
properties look like properties of the Device (as is done in
TreeItemProvider).
> As this class is already generated how can I fetch these new values?
You outlined it as a list of Property instances.
> If I write some my own code here, to fetch the values from XML, then,
> where I will save them in the model?
As contained Property instances?
>
> As, one more reply to this thread says, I guess reading from XML and
> generating a model class on the fly and compiling would help.
Compiling source is probably out of the question, but EMF supports
dynamic models and ReflectiveItemProviderAdapterFactory can support those...
> But, that should be so programmatic that end user should not know,
> that the model and editor got re-generated based on the XML input. I
> doubt at the feasibility of this task.
If you right click on an EClass when you have a *.ecore file open, you
can invoke Create Dynamic Instance... to see how dynamic models work...
>
> Thank you,
>
> Asha R.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: How to implement nodes with variable number of properties [message #424876 is a reply to message #424870] |
Sat, 08 November 2008 05:47 |
Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for the reply.
Please see the comments below.
Ed Merks wrote:
> Asha,
> Comments below.
> Asha R wrote:
>> Hi Ed,
>>
>> I have gone through the example you pointed to on your blog and felt
>> it's not something we wanted to do.
>>
>> Later, each day by day my requirement is taking a new shape (when I
>> consider about the implementation) when I think about it. Probably I
>> am terribly confused!
>>
>> So, I hope the only superman who can save me by answering my questions
>> would be probably the EMF team lead himself... :)))). Probably they
>> are very simple questions for him. Please don't mind. :-).
> Flattery will get you everywhere? :-P
:))). Even flattery got me a question mark back.
>>
>> Currently I would like to put my requirement in my simplest possible
>> terms.
>>
>> I have a class say, Device in my model. It can have a list of, say
>> another class, Property which has an attribute property_name. When I
>> select the Device node my properties editor should display these
>> property_names as the properties of this device. Of course, they can
>> be handled by ItemProviders, I understand.
> So you literally mean to model it as a list of Property instances where
> a Property is like a name/value pair... Are the values always strings?
> You can look at how TreeNodeItemProvider.getPropertyDescriptors creates
> a property descriptor for each property of the EObject referenced by
> it's data field.
>>
>> But, during the time I am generating code for this model I don't know
>> how many number of property_names I am going to have in my Device, as
>> they are not known at this point of time.
> You'll just know you can have a list...
>> So, now I have to read from an XML file that documents the Device's
>> property_names and populate this model with those property_names as
>> the properties of the device!!!
> So you're not statically going to have different "types" of devices but
> rather configure them based on some data somewhere... How will you know
> the association between any given Device instance and the information
> about what properties it's allowed to have?
>>
>> When I have already generated my model and editor for the same, I
>> wonder how can I populate these new property_names in the Device class
>> instance?
> EMF's classes have much the same limitations as Java classes in that you
> can't change them once there are instances and you can't change them at
> all if there is a generated Java implementation for them because you
> can't change the Java class itself.
Of course, this is what is scaring me as only a superman can do it. You
recognized it properly. I will have to literally - dynamically - define
these new properties in the Java Class and get it working for me. And
that's why flattery. :)). I don't think I can do it. May be reflectively
one can do it. I don't know how. So, only a list will ease our job but
still there are some questions.
>> Because even when you are handling them with the ItemProviders, the
>> ItemProvider would query a model class that has all these details!
> Yes, but if you have a list of Property children you could make their
> properties look like properties of the Device (as is done in
> TreeItemProvider).
>> As this class is already generated how can I fetch these new values?
> You outlined it as a list of Property instances.
I am talking about the new list of property instances that are to be added
on to the model. I can fetch the existing ones, but what about the new
ones, I said. So, I will have to add them on to the model now reading from
the list. Is that so? If I simply generate property descriptors from
within ItemProviders, where I will save the values, was my question. So,
the property list on the model should be updated. Am I right?
Am I not modifying the model?
>> If I write some my own code here, to fetch the values from XML, then,
>> where I will save them in the model?
> As contained Property instances?
I wonder why this question mark is. The only question I want to be sure is
this.
Am I supposed to update the existing list on the model by adding the new
values read from the XML, and generate descriptors for the same in the
ItemProvider?
>>
>> As, one more reply to this thread says, I guess reading from XML and
>> generating a model class on the fly and compiling would help.
> Compiling source is probably out of the question, but EMF supports
> dynamic models and ReflectiveItemProviderAdapterFactory can support those...
>> But, that should be so programmatic that end user should not know,
>> that the model and editor got re-generated based on the XML input. I
>> doubt at the feasibility of this task.
> If you right click on an EClass when you have a *.ecore file open, you
> can invoke Create Dynamic Instance... to see how dynamic models work...
Dynamic models work in the sense, you have all the models defined and you
don't know when user is invoking what. Where he is adding which child. If
I am right. In my case, I don't know what's my model is. So, I have to
stick to the Property instances. I need a way to define my model itself
dynamically I feel. That would be again something like providing meta data
about my model and getting a model dynamically, I guess.
So, what's a dynamic model?
One which can be crated dynamically?
Or one which can define itself dynamically?
I did not get.
Sorry for more questions.
>>
>> Thank you,
>>
>> Asha R.
>>
|
|
|
| Re: How to implement nodes with variable number of properties [message #424877 is a reply to message #424876] |
Sat, 08 November 2008 05:56 |
Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Asha R wrote:
> Hi Ed,
> Thanks for the reply.
> Please see the comments below.
> Ed Merks wrote:
>> Asha,
>> Comments below.
>> Asha R wrote:
>>> Hi Ed,
>>>
>>> I have gone through the example you pointed to on your blog and felt
>>> it's not something we wanted to do.
>>>
>>> Later, each day by day my requirement is taking a new shape (when I
>>> consider about the implementation) when I think about it. Probably I
>>> am terribly confused!
>>>
>>> So, I hope the only superman who can save me by answering my questions
>>> would be probably the EMF team lead himself... :)))). Probably they
>>> are very simple questions for him. Please don't mind. :-).
>> Flattery will get you everywhere? :-P
> :))). Even flattery got me a question mark back.
>>>
>>> Currently I would like to put my requirement in my simplest possible
>>> terms.
>>>
>>> I have a class say, Device in my model. It can have a list of, say
>>> another class, Property which has an attribute property_name. When I
>>> select the Device node my properties editor should display these
>>> property_names as the properties of this device. Of course, they can
>>> be handled by ItemProviders, I understand.
>> So you literally mean to model it as a list of Property instances where
>> a Property is like a name/value pair... Are the values always strings?
>> You can look at how TreeNodeItemProvider.getPropertyDescriptors creates
>> a property descriptor for each property of the EObject referenced by
>> it's data field.
>>>
>>> But, during the time I am generating code for this model I don't know
>>> how many number of property_names I am going to have in my Device, as
>>> they are not known at this point of time.
>> You'll just know you can have a list...
>>> So, now I have to read from an XML file that documents the Device's
>>> property_names and populate this model with those property_names as
>>> the properties of the device!!!
>> So you're not statically going to have different "types" of devices but
>> rather configure them based on some data somewhere... How will you know
>> the association between any given Device instance and the information
>> about what properties it's allowed to have?
>>>
>>> When I have already generated my model and editor for the same, I
>>> wonder how can I populate these new property_names in the Device class
>>> instance?
>> EMF's classes have much the same limitations as Java classes in that you
>> can't change them once there are instances and you can't change them at
>> all if there is a generated Java implementation for them because you
>> can't change the Java class itself.
> Of course, this is what is scaring me as only a superman can do it. You
> recognized it properly. I will have to literally - dynamically - define
> these new properties in the Java Class and get it working for me. And
> that's why flattery. :)). I don't think I can do it. May be reflectively
> one can do it. I don't know how. So, only a list will ease our job but
> still there are some questions.
>>> Because even when you are handling them with the ItemProviders, the
>>> ItemProvider would query a model class that has all these details!
>> Yes, but if you have a list of Property children you could make their
>> properties look like properties of the Device (as is done in
>> TreeItemProvider).
>>> As this class is already generated how can I fetch these new values?
>> You outlined it as a list of Property instances.
> I am talking about the new list of property instances that are to be added
> on to the model. I can fetch the existing ones, but what about the new
> ones, I said. So, I will have to add them on to the model now reading from
> the list. Is that so? If I simply generate property descriptors from
> within ItemProviders, where I will save the values, was my question. So,
> the property list on the model should be updated. Am I right?
> Am I not modifying the model?
>>> If I write some my own code here, to fetch the values from XML, then,
>>> where I will save them in the model?
>> As contained Property instances?
> I wonder why this question mark is. The only question I want to be sure is
> this.
> Am I supposed to update the existing list on the model by adding the new
> values read from the XML, and generate descriptors for the same in the
> ItemProvider?
>>>
>>> As, one more reply to this thread says, I guess reading from XML and
>>> generating a model class on the fly and compiling would help.
>> Compiling source is probably out of the question, but EMF supports
>> dynamic models and ReflectiveItemProviderAdapterFactory can support those...
>>> But, that should be so programmatic that end user should not know,
>>> that the model and editor got re-generated based on the XML input. I
>>> doubt at the feasibility of this task.
>> If you right click on an EClass when you have a *.ecore file open, you
>> can invoke Create Dynamic Instance... to see how dynamic models work...
> Dynamic models work in the sense, you have all the models defined and you
> don't know when user is invoking what. Where he is adding which child. If
> I am right. In my case, I don't know what's my model is. So, I have to
> stick to the Property instances. I need a way to define my model itself
> dynamically I feel. That would be again something like providing meta data
> about my model and getting a model dynamically, I guess.
> So, what's a dynamic model?
> One which can be crated dynamically?
I mean, one whose instances can be created dynamically?
> Or one which can define itself dynamically?
> I did not get.
> Sorry for more questions.
>>>
>>> Thank you,
>>>
>>> Asha R.
>>>
|
|
|
| Re: How to implement nodes with variable number of properties [message #424878 is a reply to message #424877] |
Sat, 08 November 2008 06:37 |
Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Ed,
Forgot to answer to your two more questions.
Please find them below.
Thank you,
Asha R.
Asha R wrote:
> Asha R wrote:
>> Hi Ed,
>> Thanks for the reply.
>> Please see the comments below.
>> Ed Merks wrote:
>>> Asha,
>>> Comments below.
>>> Asha R wrote:
>>>> Hi Ed,
>>>>
>>>> I have gone through the example you pointed to on your blog and felt
>>>> it's not something we wanted to do.
>>>>
>>>> Later, each day by day my requirement is taking a new shape (when I
>>>> consider about the implementation) when I think about it. Probably I
>>>> am terribly confused!
>>>>
>>>> So, I hope the only superman who can save me by answering my questions
>>>> would be probably the EMF team lead himself... :)))). Probably they
>>>> are very simple questions for him. Please don't mind. :-).
>>> Flattery will get you everywhere? :-P
>> :))). Even flattery got me a question mark back.
>>>>
>>>> Currently I would like to put my requirement in my simplest possible
>>>> terms.
>>>>
>>>> I have a class say, Device in my model. It can have a list of, say
>>>> another class, Property which has an attribute property_name. When I
>>>> select the Device node my properties editor should display these
>>>> property_names as the properties of this device. Of course, they can
>>>> be handled by ItemProviders, I understand.
>>> So you literally mean to model it as a list of Property instances where
>>> a Property is like a name/value pair... Are the values always strings?
>>> You can look at how TreeNodeItemProvider.getPropertyDescriptors creates
>>> a property descriptor for each property of the EObject referenced by
>>> it's data field.
Yeah, currently my values are Strings. But if it's possible to allow them
to be float and even other types it would be great. But again as string
can represent any type of data type and as our's is just a configuration
file, I guess it doesn't matter for them to be Strings with proper detail
about the data type being documented.
>>>>
>>>> But, during the time I am generating code for this model I don't know
>>>> how many number of property_names I am going to have in my Device, as
>>>> they are not known at this point of time.
>>> You'll just know you can have a list...
>>>> So, now I have to read from an XML file that documents the Device's
>>>> property_names and populate this model with those property_names as
>>>> the properties of the device!!!
>>> So you're not statically going to have different "types" of devices but
>>> rather configure them based on some data somewhere... How will you know
>>> the association between any given Device instance and the information
>>> about what properties it's allowed to have?
I am not sure about the association of the device instances. I guess that
would n't be a problem as my configuration is all about the state of the
devices i.e. the values inside the properties of the device. They connect
the devices with each other. So, there will be some programming to make
sure proper values are selected based on the values already entered for
other devices.
Later, as I am letting the user to select from and to add only available
set of devices defined in the XML I don't think there will be any issues
with the properties a device can have. Out of n number of devices that are
available, user can add some devices of his choice.
Or else am I getting your point wrong?
>>>>
>>>> When I have already generated my model and editor for the same, I
>>>> wonder how can I populate these new property_names in the Device class
>>>> instance?
>>> EMF's classes have much the same limitations as Java classes in that you
>>> can't change them once there are instances and you can't change them at
>>> all if there is a generated Java implementation for them because you
>>> can't change the Java class itself.
>> Of course, this is what is scaring me as only a superman can do it. You
>> recognized it properly. I will have to literally - dynamically - define
>> these new properties in the Java Class and get it working for me. And
>> that's why flattery. :)). I don't think I can do it. May be reflectively
>> one can do it. I don't know how. So, only a list will ease our job but
>> still there are some questions.
>>>> Because even when you are handling them with the ItemProviders, the
>>>> ItemProvider would query a model class that has all these details!
>>> Yes, but if you have a list of Property children you could make their
>>> properties look like properties of the Device (as is done in
>>> TreeItemProvider).
>>>> As this class is already generated how can I fetch these new values?
>>> You outlined it as a list of Property instances.
>> I am talking about the new list of property instances that are to be added
>> on to the model. I can fetch the existing ones, but what about the new
>> ones, I said. So, I will have to add them on to the model now reading from
>> the list. Is that so? If I simply generate property descriptors from
>> within ItemProviders, where I will save the values, was my question. So,
>> the property list on the model should be updated. Am I right?
>> Am I not modifying the model?
>>>> If I write some my own code here, to fetch the values from XML, then,
>>>> where I will save them in the model?
>>> As contained Property instances?
>> I wonder why this question mark is. The only question I want to be sure is
>> this.
>> Am I supposed to update the existing list on the model by adding the new
>> values read from the XML, and generate descriptors for the same in the
>> ItemProvider?
>>>>
>>>> As, one more reply to this thread says, I guess reading from XML and
>>>> generating a model class on the fly and compiling would help.
>>> Compiling source is probably out of the question, but EMF supports
>>> dynamic models and ReflectiveItemProviderAdapterFactory can support
those...
>>>> But, that should be so programmatic that end user should not know,
>>>> that the model and editor got re-generated based on the XML input. I
>>>> doubt at the feasibility of this task.
>>> If you right click on an EClass when you have a *.ecore file open, you
>>> can invoke Create Dynamic Instance... to see how dynamic models work...
>> Dynamic models work in the sense, you have all the models defined and you
>> don't know when user is invoking what. Where he is adding which child. If
>> I am right. In my case, I don't know what's my model is. So, I have to
>> stick to the Property instances. I need a way to define my model itself
>> dynamically I feel. That would be again something like providing meta data
>> about my model and getting a model dynamically, I guess.
>> So, what's a dynamic model?
>> One which can be crated dynamically?
> I mean, one whose instances can be created dynamically?
>> Or one which can define itself dynamically?
>> I did not get.
>> Sorry for more questions.
>>>>
>>>> Thank you,
>>>>
>>>> Asha R.
>>>>
|
|
|
| Re: How to implement nodes with variable number of properties [message #424879 is a reply to message #424876] |
Sat, 08 November 2008 13:12 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020507030602040809050709
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Asha,
Comments below.
Asha R wrote:
> Hi Ed,
>
> Thanks for the reply.
> Please see the comments below.
>
> Ed Merks wrote:
>
>> Asha,
>
>> Comments below.
>
>> Asha R wrote:
>>> Hi Ed,
>>>
>>> I have gone through the example you pointed to on your blog and felt
>>> it's not something we wanted to do.
>>>
>>> Later, each day by day my requirement is taking a new shape (when I
>>> consider about the implementation) when I think about it. Probably I
>>> am terribly confused!
>>>
>>> So, I hope the only superman who can save me by answering my
>>> questions would be probably the EMF team lead himself... :)))).
>>> Probably they are very simple questions for him. Please don't mind.
>>> :-).
>> Flattery will get you everywhere? :-P
>
> :))). Even flattery got me a question mark back.
>
>>>
>>> Currently I would like to put my requirement in my simplest possible
>>> terms.
>>>
>>> I have a class say, Device in my model. It can have a list of, say
>>> another class, Property which has an attribute property_name. When I
>>> select the Device node my properties editor should display these
>>> property_names as the properties of this device. Of course, they can
>>> be handled by ItemProviders, I understand.
>> So you literally mean to model it as a list of Property instances
>> where a Property is like a name/value pair... Are the values always
>> strings? You can look at how
>> TreeNodeItemProvider.getPropertyDescriptors creates a property
>> descriptor for each property of the EObject referenced by it's data
>> field.
>>>
>>> But, during the time I am generating code for this model I don't
>>> know how many number of property_names I am going to have in my
>>> Device, as they are not known at this point of time.
>> You'll just know you can have a list...
>>> So, now I have to read from an XML file that documents the Device's
>>> property_names and populate this model with those property_names as
>>> the properties of the device!!!
>> So you're not statically going to have different "types" of devices
>> but rather configure them based on some data somewhere... How will
>> you know the association between any given Device instance and the
>> information about what properties it's allowed to have?
>>>
>>> When I have already generated my model and editor for the same, I
>>> wonder how can I populate these new property_names in the Device
>>> class instance?
>> EMF's classes have much the same limitations as Java classes in that
>> you can't change them once there are instances and you can't change
>> them at all if there is a generated Java implementation for them
>> because you can't change the Java class itself.
>
> Of course, this is what is scaring me as only a superman can do it.
> You recognized it properly. I will have to literally - dynamically -
> define these new properties in the Java Class and get it working for
> me. And that's why flattery. :)). I don't think I can do it. May be
> reflectively one can do it. I don't know how. So, only a list will
> ease our job but still there are some questions.
>
>>> Because even when you are handling them with the ItemProviders, the
>>> ItemProvider would query a model class that has all these details!
>> Yes, but if you have a list of Property children you could make their
>> properties look like properties of the Device (as is done in
>> TreeItemProvider).
>>> As this class is already generated how can I fetch these new values?
>> You outlined it as a list of Property instances.
>
> I am talking about the new list of property instances that are to be
> added on to the model. I can fetch the existing ones, but what about
> the new ones, I said.
This is why I'm wondering how you will know what properties a specific
device is allowed to have.
> So, I will have to add them on to the model now reading from the list.
> Is that so?
I suppose so how will you know where the list is?
> If I simply generate property descriptors from within ItemProviders,
> where I will save the values, was my question.
You'll created instances of Property and add them to your containment list.
> So, the property list on the model should be updated. Am I right?
That's what you've outlined.
> Am I not modifying the model?
You're model is just a Device that contains a list of Property instances.
>
>>> If I write some my own code here, to fetch the values from XML,
>>> then, where I will save them in the model?
>> As contained Property instances?
>
> I wonder why this question mark is. The only question I want to be
> sure is this.
>
> Am I supposed to update the existing list on the model by adding the
> new values read from the XML, and generate descriptors for the same
> in the ItemProvider?
I could imagine you might, when you create the define, create the fully
populated list of allowed Property instances with default values. Then
the user wouldn't be allowed to add or remove any. Only change their values.
>
>>>
>>> As, one more reply to this thread says, I guess reading from XML and
>>> generating a model class on the fly and compiling would help.
>> Compiling source is probably out of the question, but EMF supports
>> dynamic models and ReflectiveItemProviderAdapterFactory can support
>> those...
>>> But, that should be so programmatic that end user should not know,
>>> that the model and editor got re-generated based on the XML input. I
>>> doubt at the feasibility of this task.
>> If you right click on an EClass when you have a *.ecore file open,
>> you can invoke Create Dynamic Instance... to see how dynamic models
>> work...
> Dynamic models work in the sense, you have all the models defined and
> you don't know when user is invoking what. Where he is adding which
> child. If I am right. In my case, I don't know what's my model is.
Well, as other folks have suggested, the XML file you have that lists
the allowed properties could well be converted to an EClass with
EStructuralFeatures. So it seems to me you do have the information
needed to define a model in the usual sense...
> So, I have to stick to the Property instances.
That's fine too, but it doesn't follow from what you've described
because you still need to determine what is the allowable set of
Property instances in a device and that information is coming from
somewhere.
> I need a way to define my model itself dynamically I feel. That would
> be again something like providing meta data about my model and getting
> a model dynamically, I guess.
>
> So, what's a dynamic model?
Chetan gave a helpful reference already.
> One which can be crated dynamically?
Yes, and Ecore model can be created just like any other model.
> Or one which can define itself dynamically?
> I did not get.
Chetan suggested you have a look at this:
http://www.devx.com/Java/Article/29093
>
> Sorry for more questions.
>
>>>
>>> Thank you,
>>>
>>> Asha R.
>>>
>
>
--------------020507030602040809050709
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Asha,<br>
<br>
Comments below.<br>
<br>
<br>
Asha R wrote:
<blockquote
cite="mid:6af2599b9478ba3850d9375b3eb6ac90$1@www.eclipse.org"
type="cite">Hi Ed,
<br>
<br>
Thanks for the reply.
<br>
Please see the comments below.
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">Asha,
<br>
</blockquote>
<br>
<blockquote type="cite">Comments below.
<br>
</blockquote>
<br>
<blockquote type="cite">Asha R wrote:
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
I have gone through the example you pointed to on your blog and felt
it's not something we wanted to do.
<br>
<br>
Later, each day by day my requirement is taking a new shape (when I
consider about the implementation) when I think about it. Probably I am
terribly confused!
<br>
<br>
So, I hope the only superman who can save me by answering my questions
would be probably the EMF team lead himself... :)))). Probably they are
very simple questions for him. Please don't mind. :-).
<br>
</blockquote>
Flattery will get you everywhere? :-P
<br>
</blockquote>
<br>
:))). Even flattery got me a question mark back.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite"><br>
Currently I would like to put my requirement in my simplest possible
terms.
<br>
<br>
I have a class say, Device in my model. It can have a list of, say
another class, Property which has an attribute property_name. When I
select the Device node my properties editor should display these
property_names as the properties of this device. Of course, they can be
handled by ItemProviders, I understand.
<br>
</blockquote>
So you literally mean to model it as a list of Property instances where
a Property is like a name/value pair...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to implement nodes with variable number of properties [message #424880 is a reply to message #424875] |
Sat, 08 November 2008 15:00 |
Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Chetan,
Thanks for the reply.
Please find the comments below.
Chetan Kumar wrote:
> Hey Asha,
> You said that u'll know all the information you need (about the kind of
> devices and their properties, etc) during run-time. I am guessing that
> u'll get the input in some form of xml or a specific format file.
> One thing to do is to build a model when u get this information. Let me
> elaborate. When you have all the information u need to display devices as
> nodes and properties as attributes ... then build your EMF model using
> Reflection. How ? let's say at run-time u find out that u have 2 devices
> that have different properties ... then create an EClass for each device
> and put in properties of a device as EAttributes. when u are done building
> your model, go ahead and instantiate it ...
I will try this one. But does building my model would generate the
ItemProvider for the same? I am using EMF to generate the model code and
also will be customizing the editor I am going to get along with it.
I will have to do it again manually I guess.
> This article should help you create an EMF model at run-time:
> http://www.devx.com/Java/Article/29093
> There is one more option that i can think of: looking at your problem
> from a very highlevel(forgetting about the kind of devices involved) U can
> have an EClass called "Device" with 2 references(1-*) to containers
> "property name" and "property value". PropertyName and PropertyValue can
> be 2 other classes which hold data as they r named.
> this tiny model can describe any device whatsoever right ? Give it a shot.
I already tried something like this.
A Device that has one or more Property which in turn has one PropertyName
class and one PropertyValue class.
Later, I tried something like a Device which has Property which has an
attribute called name for the property and a reference class Value with
and attribute value to hold the value of the the property.
In case of what you are suggesting, that 1-* "property name" and 1-*
"property value", how I will be able to do one to one mapping between the
both? Of course, may be I will have to consider - their index is
something that binds them together, probably. But is that perfectly right?
Designing the model can be done. But I was wondering how to add the
Property instances dynamically on to the model and get the property
descriptors for the same in the ItemProviders.
Now, with the reference you pointed to I agree I can create attributes
dynamically. Still, I will have to make sure that my <model>ItemProvider
generates the property descriptors dynamically. Am I right?
> - Chetan Kumar
|
|
|
| Re: How to implement nodes with variable number of properties [message #424881 is a reply to message #424880] |
Sat, 08 November 2008 15:15 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Asha,
Comments below.
Asha R wrote:
> Hi Chetan,
>
> Thanks for the reply.
> Please find the comments below.
>
> Chetan Kumar wrote:
>
>> Hey Asha,
>
>> You said that u'll know all the information you need (about the
>> kind of devices and their properties, etc) during run-time. I am
>> guessing that u'll get the input in some form of xml or a specific
>> format file.
>
>> One thing to do is to build a model when u get this information.
>> Let me elaborate. When you have all the information u need to display
>> devices as nodes and properties as attributes ... then build your EMF
>> model using Reflection. How ? let's say at run-time u find out that u
>> have 2 devices that have different properties ... then create an
>> EClass for each device and put in properties of a device as
>> EAttributes. when u are done building your model, go ahead and
>> instantiate it ...
>
> I will try this one. But does building my model would generate the
> ItemProvider for the same?
The reflective one works just like the default generated one.
> I am using EMF to generate the model code and also will be customizing
> the editor I am going to get along with it.
> I will have to do it again manually I guess.
You could specialize the reflective one...
>
>> This article should help you create an EMF model at run-time:
>> http://www.devx.com/Java/Article/29093
>
>> There is one more option that i can think of: looking at your
>> problem from a very highlevel(forgetting about the kind of devices
>> involved) U can have an EClass called "Device" with 2 references(1-*)
>> to containers "property name" and "property value". PropertyName and
>> PropertyValue can be 2 other classes which hold data as they r named.
>> this tiny model can describe any device whatsoever right ? Give it a
>> shot.
>
> I already tried something like this.
> A Device that has one or more Property which in turn has one
> PropertyName class and one PropertyValue class.
> Later, I tried something like a Device which has Property which has an
> attribute called name for the property and a reference class Value
> with and attribute value to hold the value of the the property.
>
> In case of what you are suggesting, that 1-* "property name" and 1-*
> "property value", how I will be able to do one to one mapping between
> the both? Of course, may be I will have to consider - their index is
> something that binds them together, probably. But is that perfectly
> right?
It seems easier to have Property be a name/value pair.
>
> Designing the model can be done. But I was wondering how to add the
> Property instances dynamically on to the model and get the property
> descriptors for the same in the ItemProviders.
You've looked at TreeNodeItemProvider yet?
> Now, with the reference you pointed to I agree I can create attributes
> dynamically. Still, I will have to make sure that my
> <model>ItemProvider generates the property descriptors dynamically. Am
> I right?
>
>> - Chetan Kumar
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to implement nodes with variable number of properties [message #424882 is a reply to message #424879] |
Sat, 08 November 2008 15:22 |
Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Ed,
I answered for the allowable set of instances question somewhere after the
reply to which you have replied now.
For convenience I would like to answer for it again, as it must be lost in
the quotes.
I will have an input XML that will give me the details of each Device and
it's properties. So, when I am allowing the user to create a node of type
Device, all he can do is, he can only select the available Device. And
when he selects the available Device now I have to update the instance for
Device with the list of properties associated with the selected Device,
from XML. So, this instance will have the list of those properties. So, I
guess there won't be any confusion as which Device will have which
properties. Then, next time my Device may have different properties. So,
all I have to do is each time the Device instance is created, read from
XML, update the property list of the Device instance, update the
ItemProvider instance of the Device to generate PropertyDescriptors for
the same.
So, I guess, I have to write some for loop that updates the model with
these new property list (I mean creates all these dynamic instances), and
one more for loop that updates the property descriptors of the item
provider. I don't know this is right way of programming or EMF way of
programming!
I hope I can write both of them inside the ItemProvider itself by
obtaining the reference of the Device instance.
:((.
Ed Merks wrote:
> Asha,
> Comments below.
> Asha R wrote:
>> Hi Ed,
>>
>> Thanks for the reply.
>> Please see the comments below.
>>
>> Ed Merks wrote:
>>
>>> Asha,
>>
>>> Comments below.
>>
>>> Asha R wrote:
>>>> Hi Ed,
>>>>
>>>> I have gone through the example you pointed to on your blog and felt
>>>> it's not something we wanted to do.
>>>>
>>>> Later, each day by day my requirement is taking a new shape (when I
>>>> consider about the implementation) when I think about it. Probably I
>>>> am terribly confused!
>>>>
>>>> So, I hope the only superman who can save me by answering my
>>>> questions would be probably the EMF team lead himself... :)))).
>>>> Probably they are very simple questions for him. Please don't mind.
>>>> :-).
>>> Flattery will get you everywhere? :-P
>>
>> :))). Even flattery got me a question mark back.
>>
>>>>
>>>> Currently I would like to put my requirement in my simplest possible
>>>> terms.
>>>>
>>>> I have a class say, Device in my model. It can have a list of, say
>>>> another class, Property which has an attribute property_name. When I
>>>> select the Device node my properties editor should display these
>>>> property_names as the properties of this device. Of course, they can
>>>> be handled by ItemProviders, I understand.
>>> So you literally mean to model it as a list of Property instances
>>> where a Property is like a name/value pair... Are the values always
>>> strings? You can look at how
>>> TreeNodeItemProvider.getPropertyDescriptors creates a property
>>> descriptor for each property of the EObject referenced by it's data
>>> field.
>>>>
>>>> But, during the time I am generating code for this model I don't
>>>> know how many number of property_names I am going to have in my
>>>> Device, as they are not known at this point of time.
>>> You'll just know you can have a list...
>>>> So, now I have to read from an XML file that documents the Device's
>>>> property_names and populate this model with those property_names as
>>>> the properties of the device!!!
>>> So you're not statically going to have different "types" of devices
>>> but rather configure them based on some data somewhere... How will
>>> you know the association between any given Device instance and the
>>> information about what properties it's allowed to have?
>>>>
>>>> When I have already generated my model and editor for the same, I
>>>> wonder how can I populate these new property_names in the Device
>>>> class instance?
>>> EMF's classes have much the same limitations as Java classes in that
>>> you can't change them once there are instances and you can't change
>>> them at all if there is a generated Java implementation for them
>>> because you can't change the Java class itself.
>>
>> Of course, this is what is scaring me as only a superman can do it.
>> You recognized it properly. I will have to literally - dynamically -
>> define these new properties in the Java Class and get it working for
>> me. And that's why flattery. :)). I don't think I can do it. May be
>> reflectively one can do it. I don't know how. So, only a list will
>> ease our job but still there are some questions.
>>
>>>> Because even when you are handling them with the ItemProviders, the
>>>> ItemProvider would query a model class that has all these details!
>>> Yes, but if you have a list of Property children you could make their
>>> properties look like properties of the Device (as is done in
>>> TreeItemProvider).
>>>> As this class is already generated how can I fetch these new values?
>>> You outlined it as a list of Property instances.
>>
>> I am talking about the new list of property instances that are to be
>> added on to the model. I can fetch the existing ones, but what about
>> the new ones, I said.
> This is why I'm wondering how you will know what properties a specific
> device is allowed to have.
>> So, I will have to add them on to the model now reading from the list.
>> Is that so?
> I suppose so how will you know where the list is?
>> If I simply generate property descriptors from within ItemProviders,
>> where I will save the values, was my question.
> You'll created instances of Property and add them to your containment list.
>> So, the property list on the model should be updated. Am I right?
> That's what you've outlined.
>> Am I not modifying the model?
> You're model is just a Device that contains a list of Property instances.
>>
>>>> If I write some my own code here, to fetch the values from XML,
>>>> then, where I will save them in the model?
>>> As contained Property instances?
>>
>> I wonder why this question mark is. The only question I want to be
>> sure is this.
>>
>> Am I supposed to update the existing list on the model by adding the
>> new values read from the XML, and generate descriptors for the same
>> in the ItemProvider?
> I could imagine you might, when you create the define, create the fully
> populated list of allowed Property instances with default values. Then
> the user wouldn't be allowed to add or remove any. Only change their values.
>>
>>>>
>>>> As, one more reply to this thread says, I guess reading from XML and
>>>> generating a model class on the fly and compiling would help.
>>> Compiling source is probably out of the question, but EMF supports
>>> dynamic models and ReflectiveItemProviderAdapterFactory can support
>>> those...
>>>> But, that should be so programmatic that end user should not know,
>>>> that the model and editor got re-generated based on the XML input. I
>>>> doubt at the feasibility of this task.
>>> If you right click on an EClass when you have a *.ecore file open,
>>> you can invoke Create Dynamic Instance... to see how dynamic models
>>> work...
>> Dynamic models work in the sense, you have all the models defined and
>> you don't know when user is invoking what. Where he is adding which
>> child. If I am right. In my case, I don't know what's my model is.
> Well, as other folks have suggested, the XML file you have that lists
> the allowed properties could well be converted to an EClass with
> EStructuralFeatures. So it seems to me you do have the information
> needed to define a model in the usual sense...
>> So, I have to stick to the Property instances.
> That's fine too, but it doesn't follow from what you've described
> because you still need to determine what is the allowable set of
> Property instances in a device and that information is coming from
> somewhere.
>> I need a way to define my model itself dynamically I feel. That would
>> be again something like providing meta data about my model and getting
>> a model dynamically, I guess.
>>
>> So, what's a dynamic model?
> Chetan gave a helpful reference already.
>> One which can be crated dynamically?
> Yes, and Ecore model can be created just like any other model.
>> Or one which can define itself dynamically?
>> I did not get.
> Chetan suggested you have a look at this:
> http://www.devx.com/Java/Article/29093
>>
>> Sorry for more questions.
>>
>>>>
>>>> Thank you,
>>>>
>>>> Asha R.
>>>>
>>
>>
|
|
|
| Re: How to implement nodes with variable number of properties [message #424883 is a reply to message #424881] |
Sat, 08 November 2008 15:28 |
Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for the reply.
I have looked into it but did not get much input to my brain as I was
thinking my task is complicated.
But surely I will look into it once again.
Thank you,
Asha R.
Ed Merks wrote:
> Asha,
> Comments below.
> Asha R wrote:
>> Hi Chetan,
>>
>> Thanks for the reply.
>> Please find the comments below.
>>
>> Chetan Kumar wrote:
>>
>>> Hey Asha,
>>
>>> You said that u'll know all the information you need (about the
>>> kind of devices and their properties, etc) during run-time. I am
>>> guessing that u'll get the input in some form of xml or a specific
>>> format file.
>>
>>> One thing to do is to build a model when u get this information.
>>> Let me elaborate. When you have all the information u need to display
>>> devices as nodes and properties as attributes ... then build your EMF
>>> model using Reflection. How ? let's say at run-time u find out that u
>>> have 2 devices that have different properties ... then create an
>>> EClass for each device and put in properties of a device as
>>> EAttributes. when u are done building your model, go ahead and
>>> instantiate it ...
>>
>> I will try this one. But does building my model would generate the
>> ItemProvider for the same?
> The reflective one works just like the default generated one.
>> I am using EMF to generate the model code and also will be customizing
>> the editor I am going to get along with it.
>> I will have to do it again manually I guess.
> You could specialize the reflective one...
>>
>>> This article should help you create an EMF model at run-time:
>>> http://www.devx.com/Java/Article/29093
>>
>>> There is one more option that i can think of: looking at your
>>> problem from a very highlevel(forgetting about the kind of devices
>>> involved) U can have an EClass called "Device" with 2 references(1-*)
>>> to containers "property name" and "property value". PropertyName and
>>> PropertyValue can be 2 other classes which hold data as they r named.
>>> this tiny model can describe any device whatsoever right ? Give it a
>>> shot.
>>
>> I already tried something like this.
>> A Device that has one or more Property which in turn has one
>> PropertyName class and one PropertyValue class.
>> Later, I tried something like a Device which has Property which has an
>> attribute called name for the property and a reference class Value
>> with and attribute value to hold the value of the the property.
>>
>> In case of what you are suggesting, that 1-* "property name" and 1-*
>> "property value", how I will be able to do one to one mapping between
>> the both? Of course, may be I will have to consider - their index is
>> something that binds them together, probably. But is that perfectly
>> right?
> It seems easier to have Property be a name/value pair.
>>
>> Designing the model can be done. But I was wondering how to add the
>> Property instances dynamically on to the model and get the property
>> descriptors for the same in the ItemProviders.
> You've looked at TreeNodeItemProvider yet?
>> Now, with the reference you pointed to I agree I can create attributes
>> dynamically. Still, I will have to make sure that my
>> <model>ItemProvider generates the property descriptors dynamically. Am
>> I right?
>>
>>> - Chetan Kumar
>>
>>
|
|
|
| Re: How to implement nodes with variable number of properties [message #424884 is a reply to message #424882] |
Sat, 08 November 2008 15:37 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Asha,
Comments below.
Asha R wrote:
> Hi Ed,
>
> I answered for the allowable set of instances question somewhere after
> the reply to which you have replied now.
>
> For convenience I would like to answer for it again, as it must be
> lost in the quotes.
>
> I will have an input XML that will give me the details of each Device
> and it's properties.
So you might map each to a Device to an EClass and map each property to
an EStructuralFeature...
> So, when I am allowing the user to create a node of type Device, all
> he can do is, he can only select the available Device.
Alternatively you'd have the simple Device/Properties model you talked
about and this step would make a copy of the prototype instance.
> And when he selects the available Device now I have to update the
> instance for Device with the list of properties associated with the
> selected Device, from XML.
So you could populate the Device with the predetermined list of allowed
Property instances.
> So, this instance will have the list of those properties. So, I guess
> there won't be any confusion as which Device will have which
> properties. Then, next time my Device may have different properties.
The prototype or the instance that already exists with populated
information?
> So, all I have to do is each time the Device instance is created, read
> from XML, update the property list of the Device instance, update the
> ItemProvider instance of the Device to generate PropertyDescriptors
> for the same.
I'm imagining the DeviceItemProvider acting much like the
TreeNodeItemProvider and simply collecting the one descriptor from each
Property instance...
>
> So, I guess, I have to write some for loop that updates the model with
> these new property list (I mean creates all these dynamic instances),
> and one more for loop that updates the property descriptors of the
> item provider. I don't know this is right way of programming or EMF
> way of programming!
>
> I hope I can write both of them inside the ItemProvider itself by
> obtaining the reference of the Device instance.
I imagine you could. You could have one property descriptor for the
Device as a whole, that's a choice of all the types of devices, and then
a property descriptor per Property instance....
>
> :((.
>
> Ed Merks wrote:
>
>> Asha,
>
>> Comments below.
>
>
>> Asha R wrote:
>>> Hi Ed,
>>>
>>> Thanks for the reply.
>>> Please see the comments below.
>>>
>>> Ed Merks wrote:
>>>
>>>> Asha,
>>>
>>>> Comments below.
>>>
>>>> Asha R wrote:
>>>>> Hi Ed,
>>>>>
>>>>> I have gone through the example you pointed to on your blog and
>>>>> felt it's not something we wanted to do.
>>>>>
>>>>> Later, each day by day my requirement is taking a new shape (when
>>>>> I consider about the implementation) when I think about it.
>>>>> Probably I am terribly confused!
>>>>>
>>>>> So, I hope the only superman who can save me by answering my
>>>>> questions would be probably the EMF team lead himself... :)))).
>>>>> Probably they are very simple questions for him. Please don't
>>>>> mind. :-).
>>>> Flattery will get you everywhere? :-P
>>>
>>> :))). Even flattery got me a question mark back.
>>>
>>>>>
>>>>> Currently I would like to put my requirement in my simplest
>>>>> possible terms.
>>>>>
>>>>> I have a class say, Device in my model. It can have a list of, say
>>>>> another class, Property which has an attribute property_name. When
>>>>> I select the Device node my properties editor should display these
>>>>> property_names as the properties of this device. Of course, they
>>>>> can be handled by ItemProviders, I understand.
>>>> So you literally mean to model it as a list of Property instances
>>>> where a Property is like a name/value pair... Are the values
>>>> always strings? You can look at how
>>>> TreeNodeItemProvider.getPropertyDescriptors creates a property
>>>> descriptor for each property of the EObject referenced by it's data
>>>> field.
>>>>>
>>>>> But, during the time I am generating code for this model I don't
>>>>> know how many number of property_names I am going to have in my
>>>>> Device, as they are not known at this point of time.
>>>> You'll just know you can have a list...
>>>>> So, now I have to read from an XML file that documents the
>>>>> Device's property_names and populate this model with those
>>>>> property_names as the properties of the device!!!
>>>> So you're not statically going to have different "types" of devices
>>>> but rather configure them based on some data somewhere... How will
>>>> you know the association between any given Device instance and the
>>>> information about what properties it's allowed to have?
>>>>>
>>>>> When I have already generated my model and editor for the same, I
>>>>> wonder how can I populate these new property_names in the Device
>>>>> class instance?
>>>> EMF's classes have much the same limitations as Java classes in
>>>> that you can't change them once there are instances and you can't
>>>> change them at all if there is a generated Java implementation for
>>>> them because you can't change the Java class itself.
>>>
>>> Of course, this is what is scaring me as only a superman can do it.
>>> You recognized it properly. I will have to literally - dynamically -
>>> define these new properties in the Java Class and get it working for
>>> me. And that's why flattery. :)). I don't think I can do it. May be
>>> reflectively one can do it. I don't know how. So, only a list will
>>> ease our job but still there are some questions.
>>>
>>>>> Because even when you are handling them with the ItemProviders,
>>>>> the ItemProvider would query a model class that has all these
>>>>> details!
>>>> Yes, but if you have a list of Property children you could make
>>>> their properties look like properties of the Device (as is done in
>>>> TreeItemProvider).
>>>>> As this class is already generated how can I fetch these new values?
>>>> You outlined it as a list of Property instances.
>>>
>>> I am talking about the new list of property instances that are to be
>>> added on to the model. I can fetch the existing ones, but what about
>>> the new ones, I said.
>> This is why I'm wondering how you will know what properties a
>> specific device is allowed to have.
>>> So, I will have to add them on to the model now reading from the
>>> list. Is that so?
>> I suppose so how will you know where the list is?
>>> If I simply generate property descriptors from within ItemProviders,
>>> where I will save the values, was my question.
>> You'll created instances of Property and add them to your containment
>> list.
>>> So, the property list on the model should be updated. Am I right?
>> That's what you've outlined.
>>> Am I not modifying the model?
>> You're model is just a Device that contains a list of Property
>> instances.
>>>
>>>>> If I write some my own code here, to fetch the values from XML,
>>>>> then, where I will save them in the model?
>>>> As contained Property instances?
>>>
>>> I wonder why this question mark is. The only question I want to be
>>> sure is this.
>>>
>>> Am I supposed to update the existing list on the model by adding the
>>> new values read from the XML, and generate descriptors for the same
>>> in the ItemProvider?
>> I could imagine you might, when you create the define, create the
>> fully populated list of allowed Property instances with default
>> values. Then the user wouldn't be allowed to add or remove any. Only
>> change their values.
>>>
>>>>>
>>>>> As, one more reply to this thread says, I guess reading from XML
>>>>> and generating a model class on the fly and compiling would help.
>>>> Compiling source is probably out of the question, but EMF supports
>>>> dynamic models and ReflectiveItemProviderAdapterFactory can support
>>>> those...
>>>>> But, that should be so programmatic that end user should not know,
>>>>> that the model and editor got re-generated based on the XML input.
>>>>> I doubt at the feasibility of this task.
>>>> If you right click on an EClass when you have a *.ecore file open,
>>>> you can invoke Create Dynamic Instance... to see how dynamic models
>>>> work...
>>> Dynamic models work in the sense, you have all the models defined
>>> and you don't know when user is invoking what. Where he is adding
>>> which child. If I am right. In my case, I don't know what's my model
>>> is.
>> Well, as other folks have suggested, the XML file you have that lists
>> the allowed properties could well be converted to an EClass with
>> EStructuralFeatures. So it seems to me you do have the information
>> needed to define a model in the usual sense...
>>> So, I have to stick to the Property instances.
>> That's fine too, but it doesn't follow from what you've described
>> because you still need to determine what is the allowable set of
>> Property instances in a device and that information is coming from
>> somewhere.
>>> I need a way to define my model itself dynamically I feel. That
>>> would be again something like providing meta data about my model and
>>> getting a model dynamically, I guess.
>>>
>>> So, what's a dynamic model?
>> Chetan gave a helpful reference already.
>>> One which can be crated dynamically?
>> Yes, and Ecore model can be created just like any other model.
>>> Or one which can define itself dynamically?
>>> I did not get.
>> Chetan suggested you have a look at this:
>
>> http://www.devx.com/Java/Article/29093
>
>>>
>>> Sorry for more questions.
>>>
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Asha R.
>>>>>
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to implement nodes with variable number of properties [message #424890 is a reply to message #424884] |
Sun, 09 November 2008 05:47 |
Asha Ramegowda
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for the reply.
I will try this one and come back to this forum again. :-).
Please see the comments below.
Thank you,
Asha R.
Ed Merks wrote:
> Asha,
> Comments below.
> Asha R wrote:
>> Hi Ed,
>>
>> I answered for the allowable set of instances question somewhere after
>> the reply to which you have replied now.
>>
>> For convenience I would like to answer for it again, as it must be
>> lost in the quotes.
>>
>> I will have an input XML that will give me the details of each Device
>> and it's properties.
> So you might map each to a Device to an EClass and map each property to
> an EStructuralFeature...
>> So, when I am allowing the user to create a node of type Device, all
>> he can do is, he can only select the available Device.
> Alternatively you'd have the simple Device/Properties model you talked
> about and this step would make a copy of the prototype instance.
Yeah, I will have the model and this step will create and instance of the
Device with a list of Property that contains each of the properties
mentioned in the XML.
>> And when he selects the available Device now I have to update the
>> instance for Device with the list of properties associated with the
>> selected Device, from XML.
> So you could populate the Device with the predetermined list of allowed
> Property instances.
>> So, this instance will have the list of those properties. So, I guess
>> there won't be any confusion as which Device will have which
>> properties. Then, next time my Device may have different properties.
> The prototype or the instance that already exists with populated
> information?
The prototype, not the instance that already exists with the populated
information. I mean, next time when I have to instantiate the next Device,
I will have the new properties associated with that Device as per the XML
detail.
>> So, all I have to do is each time the Device instance is created, read
>> from XML, update the property list of the Device instance, update the
>> ItemProvider instance of the Device to generate PropertyDescriptors
>> for the same.
> I'm imagining the DeviceItemProvider acting much like the
> TreeNodeItemProvider and simply collecting the one descriptor from each
> Property instance...
>>
>> So, I guess, I have to write some for loop that updates the model with
>> these new property list (I mean creates all these dynamic instances),
>> and one more for loop that updates the property descriptors of the
>> item provider. I don't know this is right way of programming or EMF
>> way of programming!
>>
>> I hope I can write both of them inside the ItemProvider itself by
>> obtaining the reference of the Device instance.
> I imagine you could. You could have one property descriptor for the
> Device as a whole, that's a choice of all the types of devices, and then
> a property descriptor per Property instance....
>>
>> :((.
>>
>> Ed Merks wrote:
>>
>>> Asha,
>>
>>> Comments below.
>>
>>
>>> Asha R wrote:
>>>> Hi Ed,
>>>>
>>>> Thanks for the reply.
>>>> Please see the comments below.
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Asha,
>>>>
>>>>> Comments below.
>>>>
>>>>> Asha R wrote:
>>>>>> Hi Ed,
>>>>>>
>>>>>> I have gone through the example you pointed to on your blog and
>>>>>> felt it's not something we wanted to do.
>>>>>>
>>>>>> Later, each day by day my requirement is taking a new shape (when
>>>>>> I consider about the implementation) when I think about it.
>>>>>> Probably I am terribly confused!
>>>>>>
>>>>>> So, I hope the only superman who can save me by answering my
>>>>>> questions would be probably the EMF team lead himself... :)))).
>>>>>> Probably they are very simple questions for him. Please don't
>>>>>> mind. :-).
>>>>> Flattery will get you everywhere? :-P
>>>>
>>>> :))). Even flattery got me a question mark back.
>>>>
>>>>>>
>>>>>> Currently I would like to put my requirement in my simplest
>>>>>> possible terms.
>>>>>>
>>>>>> I have a class say, Device in my model. It can have a list of, say
>>>>>> another class, Property which has an attribute property_name. When
>>>>>> I select the Device node my properties editor should display these
>>>>>> property_names as the properties of this device. Of course, they
>>>>>> can be handled by ItemProviders, I understand.
>>>>> So you literally mean to model it as a list of Property instances
>>>>> where a Property is like a name/value pair... Are the values
>>>>> always strings? You can look at how
>>>>> TreeNodeItemProvider.getPropertyDescriptors creates a property
>>>>> descriptor for each property of the EObject referenced by it's data
>>>>> field.
>>>>>>
>>>>>> But, during the time I am generating code for this model I don't
>>>>>> know how many number of property_names I am going to have in my
>>>>>> Device, as they are not known at this point of time.
>>>>> You'll just know you can have a list...
>>>>>> So, now I have to read from an XML file that documents the
>>>>>> Device's property_names and populate this model with those
>>>>>> property_names as the properties of the device!!!
>>>>> So you're not statically going to have different "types" of devices
>>>>> but rather configure them based on some data somewhere... How will
>>>>> you know the association between any given Device instance and the
>>>>> information about what properties it's allowed to have?
>>>>>>
>>>>>> When I have already generated my model and editor for the same, I
>>>>>> wonder how can I populate these new property_names in the Device
>>>>>> class instance?
>>>>> EMF's classes have much the same limitations as Java classes in
>>>>> that you can't change them once there are instances and you can't
>>>>> change them at all if there is a generated Java implementation for
>>>>> them because you can't change the Java class itself.
>>>>
>>>> Of course, this is what is scaring me as only a superman can do it.
>>>> You recognized it properly. I will have to literally - dynamically -
>>>> define these new properties in the Java Class and get it working for
>>>> me. And that's why flattery. :)). I don't think I can do it. May be
>>>> reflectively one can do it. I don't know how. So, only a list will
>>>> ease our job but still there are some questions.
>>>>
>>>>>> Because even when you are handling them with the ItemProviders,
>>>>>> the ItemProvider would query a model class that has all these
>>>>>> details!
>>>>> Yes, but if you have a list of Property children you could make
>>>>> their properties look like properties of the Device (as is done in
>>>>> TreeItemProvider).
>>>>>> As this class is already generated how can I fetch these new values?
>>>>> You outlined it as a list of Property instances.
>>>>
>>>> I am talking about the new list of property instances that are to be
>>>> added on to the model. I can fetch the existing ones, but what about
>>>> the new ones, I said.
>>> This is why I'm wondering how you will know what properties a
>>> specific device is allowed to have.
>>>> So, I will have to add them on to the model now reading from the
>>>> list. Is that so?
>>> I suppose so how will you know where the list is?
>>>> If I simply generate property descriptors from within ItemProviders,
>>>> where I will save the values, was my question.
>>> You'll created instances of Property and add them to your containment
>>> list.
>>>> So, the property list on the model should be updated. Am I right?
>>> That's what you've outlined.
>>>> Am I not modifying the model?
>>> You're model is just a Device that contains a list of Property
>>> instances.
>>>>
>>>>>> If I write some my own code here, to fetch the values from XML,
>>>>>> then, where I will save them in the model?
>>>>> As contained Property instances?
>>>>
>>>> I wonder why this question mark is. The only question I want to be
>>>> sure is this.
>>>>
>>>> Am I supposed to update the existing list on the model by adding the
>>>> new values read from the XML, and generate descriptors for the same
>>>> in the ItemProvider?
>>> I could imagine you might, when you create the define, create the
>>> fully populated list of allowed Property instances with default
>>> values. Then the user wouldn't be allowed to add or remove any. Only
>>> change their values.
>>>>
>>>>>>
>>>>>> As, one more reply to this thread says, I guess reading from XML
>>>>>> and generating a model class on the fly and compiling would help.
>>>>> Compiling source is probably out of the question, but EMF supports
>>>>> dynamic models and ReflectiveItemProviderAdapterFactory can support
>>>>> those...
>>>>>> But, that should be so programmatic that end user should not know,
>>>>>> that the model and editor got re-generated based on the XML input.
>>>>>> I doubt at the feasibility of this task.
>>>>> If you right click on an EClass when you have a *.ecore file open,
>>>>> you can invoke Create Dynamic Instance... to see how dynamic models
>>>>> work...
>>>> Dynamic models work in the sense, you have all the models defined
>>>> and you don't know when user is invoking what. Where he is adding
>>>> which child. If I am right. In my case, I don't know what's my model
>>>> is.
>>> Well, as other folks have suggested, the XML file you have that lists
>>> the allowed properties could well be converted to an EClass with
>>> EStructuralFeatures. So it seems to me you do have the information
>>> needed to define a model in the usual sense...
>>>> So, I have to stick to the Property instances.
>>> That's fine too, but it doesn't follow from what you've described
>>> because you still need to determine what is the allowable set of
>>> Property instances in a device and that information is coming from
>>> somewhere.
>>>> I need a way to define my model itself dynamically I feel. That
>>>> would be again something like providing meta data about my model and
>>>> getting a model dynamically, I guess.
>>>>
>>>> So, what's a dynamic model?
>>> Chetan gave a helpful reference already.
>>>> One which can be crated dynamically?
>>> Yes, and Ecore model can be created just like any other model.
>>>> Or one which can define itself dynamically?
>>>> I did not get.
>>> Chetan suggested you have a look at this:
>>
>>> http://www.devx.com/Java/Article/29093
>>
>>>>
>>>> Sorry for more questions.
>>>>
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Asha R.
>>>>>>
>>>>
>>>>
>>
>>
|
|
|
Goto Forum:
Current Time: Tue Apr 23 16:16:46 GMT 2024
Powered by FUDForum. Page generated in 0.05454 seconds |
] 
Search
Help
Register
Login
Home
