Home » Eclipse Projects » Eclipse Platform » Generic form editor for EMF EObjects
|
| Re: Generic form editor for EMF EObjects [message #327089 is a reply to message #327087] |
Wed, 09 April 2008 12:24   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------070505010503020002070408
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Jonas,
It's best to ask EMF questions on the EMF newsgroup, which I've added to
the "to" list of the reply.
Jonas wrote:
> Hello,
> I guess this has been done and answered before, but i was not able to
> find sth. helpful.
>
> I would like to build a generic editor for emf models, cause i cannot
> hard-code a seperate form for every emf element in my application.
> That means the editor has to look into the emf model and create a form
> for all the avaiable features.
The properties view is like a form. I was experimenting with using data
binding to generate a form using the same information as is used to
generate the properties view.
>
> Also i would like to enhance the emf model with some custom
> information about the visualizations of the attributes, for instance
> to group them on the editor form.
Michael Scharf did something interesting a while back:
< http://scharf.gr/eclipse/eclipsecon2006/Unconventional_but_S imple_Annotations_to_Customize_EMF_Editors/>
http://scharf.gr/eclipse/eclipsecon2006/Unconventional_but_S imple_Annotations_to_Customize_EMF_Editors/
>
> Maybe someone has a hint how to do this or a link to an example
> solving one or both problems.
> Thanks for any help!
>
> Jonas
>
--------------070505010503020002070408
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">
Jonas,<br>
<br>
It's best to ask EMF questions on the EMF newsgroup, which I've added
to the "to" list of the reply.<br>
<br>
<br>
Jonas wrote:
<blockquote
cite="mid:a0fdfc78bc144e53f8f88633b2798abf$1@www.eclipse.org"
type="cite">Hello,
<br>
I guess this has been done and answered before, but i was not able to
find sth. helpful.
<br>
<br>
I would like to build a generic editor for emf models, cause i cannot
hard-code a seperate form for every emf element in my application. That
means the editor has to look into the emf model and create a form for
all the avaiable features.
<br>
</blockquote>
The properties view is like a form.
|
|
| | |
| Re: Generic form editor for EMF EObjects [message #327117 is a reply to message #327112] |
Thu, 10 April 2008 12:54 |
| Eclipse User |
|
|
|
Originally posted by: dennis.huebner.gmail.org
Hi Roman,
the Generic Editor is already in oAW-Repository. There is also a little
example project. It works with EMF2.3 and EMF-Databinding. We will build
a itemis eclipse-oAW distribution where the editor will be included.
Later with oAW5 the editor should be included in official releases.
Regards,
Dennis.
Roman Porotnikov schrieb:
> There is also something from itemis, they blog about it at
> http://apps.itemis.de/roller/itemislabkiel/entry/generic_mod elling .
>
> There is a link to a video demonstration, but they say "We're not sure
> where exactly we're going to release it".
>
> ~
> Roman
>
>
> Ed Merks wrote:
>> Jonas,
>>
>> It's best to ask EMF questions on the EMF newsgroup, which I've added
>> to the "to" list of the reply.
>>
>>
>> Jonas wrote:
>>> Hello,
>>> I guess this has been done and answered before, but i was not able to
>>> find sth. helpful.
>>>
>>> I would like to build a generic editor for emf models, cause i cannot
>>> hard-code a seperate form for every emf element in my application.
>>> That means the editor has to look into the emf model and create a
>>> form for all the avaiable features.
>> The properties view is like a form. I was experimenting with using
>> data binding to generate a form using the same information as is used
>> to generate the properties view.
>>>
>>> Also i would like to enhance the emf model with some custom
>>> information about the visualizations of the attributes, for instance
>>> to group them on the editor form.
>> Michael Scharf did something interesting a while back:
>> < http://scharf.gr/eclipse/eclipsecon2006/Unconventional_but_S imple_Annotations_to_Customize_EMF_Editors/>
>>
>>
>>
>> http://scharf.gr/eclipse/eclipsecon2006/Unconventional_but_S imple_Annotations_to_Customize_EMF_Editors/
>>
>>
>>>
>>> Maybe someone has a hint how to do this or a link to an example
>>> solving one or both problems.
>>> Thanks for any help!
>>>
>>> Jonas
>>>
>>
|
|
| | | | |
| Re: Generic form editor for EMF EObjects [message #327138 is a reply to message #327135] |
Fri, 11 April 2008 10:31 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------040300080608060204060703
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Jonas,
There's no problem with posting to a more general newsgroup the first
time. It happens plenty. Eclipse is one big happy family so it's
sometimes hard to find exactly the right place to ask a specific question.
If you don't read the Planet Eclipse blogs, you'll likely be
interested. Someone had a post on topic very similar to your question
yesterday:
http://www.planeteclipse.org/planet/
http://eclipser-blog.blogspot.com/2008/04/automatic-generati on-of-emf-editor-idea.html
Michael has a blog there as well.
http://michaelscharf.blogspot.com/
I sent him a note indicating that you are interested in his work and
asking him to look at this note thread...
Jonas wrote:
> Thank you Ed for moving the post and sorry, i am quite new to the
> community...
>
>> It's best to ask EMF questions on the EMF newsgroup, which I've added
>> to the "to" list of the reply.
>
> http://scharf.gr/eclipse/eclipsecon2006/Unconventional_but_S imple_Annotations_to_Customize_EMF_Editors/
>
>
> Do you have any idea how to get in contact with michael or which
> project he is working on? the presentation looks very promising.
>
>
>
--------------040300080608060204060703
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">
Jonas,<br>
<br>
There's no problem with posting to a more general newsgroup the first
time.
|
|
|
| Re: Generic form editor for EMF EObjects [message #327149 is a reply to message #327135] |
Fri, 11 April 2008 15:45 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-newsgroups.scharf.gr
Hi Jonas,
this project was a typical "Teflon Project"[1].
I put it together in a relatively short time and
it was great do demo. We have also build some
products on top. Unfortunately, my management
did not understand the value of the project
(although I played all the tricks of a Teflon-programmer)
and now is has been degraded from generic solution
for a range of problems to a specific solution
for one particular project.
The sad side of the story is that inside my company
there is the mis-perception that the generic editor is
huge and complicated. And this comes mainly from the
fact that I use EMF and the underlying data model.
And because EMF dragged in a lot of other plugins [2]
at that time, the perception was that my framework
is heavyweight (because the all of emf including
JDT were seen as part of my framework).
Ironically nobody wants to use my "heavy wight" framework,
and therefore many new frameworks were written implementing
their own (incomplete) version of EMF. One of those "lightweight"
UI frameworks that was created is 10 times bigger than my code
(if you don't count EMF as part of the generic editor).
We are still working on the generic editor
as part of the project it has been confined to in the hope
to put it into the light when its time has come....
At the moment we are not working on the UI part of the
framework, but on the infrastructure needed for that
particular project. But in the not to far future we want
to refactor/rewrite the generic UI part. Maybe we join
our forces with the OAW generic editor.
As shown in the presentation, I decided to use annotations
to drive the UI. We call those annotations UIHints, because
they give a hint to the renderer how to display the properties
in the UI. I deliberately chose the term "hint" because the
ui-engine might decide to ignore some hints. It is like
HTML in the old days, where you specified this is a header,
or emphasized and the html browser does the layout for you
(or like LaTex).
This project started 4 years ago, at that time there was
noting like OCL available for EMF. But to do the UI, you
also need validation and some basic form of enable/disable
support for controls. I had written a tiny expression
evaluator based on OQL [3]. With OQL the user can specify
disablement of attributes as well as validation.
Today I'd use CQL [4] or openArchitectureWare Check [5].
I addition, I created my own incarnation of databinding [6],
because it was not available at that time.
Unfortunately, the weakest part of our generic editor is
the engine that interprets the UIHints and turns it into
the UI. It started as a very small set of hints and the
number of hint grew but I did not have time to refactor
the engine, although I have some ideas hoe I'd do it.
I think it would be great if we could put all the different
efforts together and create a solid data-driven UI.
Note: although we use EMF annotations for the UIHints there is
nothing that prevents us from absrtacting this out. All you
need is to get the UI hints for a given element:
UIHint[] HintAdapter.getHints(Object object)
Note 2: one other obvious idea is to extend emfatic [8] to make
the annotations have a Metamodel. Now annotations are free-form.
When you have a metamodel for annotations you can create an
text editor that (using TMF [7]). We did some experiments using
xText [9] to create our own version of emfatic.
I think the biggest contribution I can make is to share my
experience, the good and the bad decisions we made on our
generic editor (I switch here between "my" and "our" framework,
because most of the design and implementation was done by
me with Anton Leherbauer contributing some of the initial
UIHint engine and doing some bug fixing and Richard Memory
working right now on the framework)
Michael
[1] http://ed-merks.blogspot.com/2008/04/teflon-programming.html
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=106804
[3] http://en.wikipedia.org/wiki/Object_Query_Language
[4] http://www.eclipse.org/modeling/mdt/?project=ocl#ocl
[5] http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/core_re ference.html
[6] http://wiki.eclipse.org/index.php/JFace_Data_Binding
[7] http://www.eclipse.org/proposals/tmf/
[8] http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/using_t he_emfatic_ecore_editor.html
[9] http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/xtext_r eference.html
> Thank you Ed for moving the post and sorry, i am quite new to the
> community...
>
>> It's best to ask EMF questions on the EMF newsgroup, which I've added
>> to the "to" list of the reply.
>
> http://scharf.gr/eclipse/eclipsecon2006/Unconventional_but_S imple_Annotations_to_Customize_EMF_Editors/
>
>
> Do you have any idea how to get in contact with michael or which project
> he is working on? the presentation looks very promising.
>
>
>
--
Michael Scharf
Wind River Systems GmbH
Michael (dot) Scharf [at] WindRiver {dot} com
http://www.WindRiver.com
http://MichaelScharf.blogspot.com/
|
|
| |
| Re: Generic form editor for EMF EObjects [message #327154 is a reply to message #327149] |
Fri, 11 April 2008 17:44 |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Michael,
Interesting that you use UIHints. I have been working for a few months on generating web ui's on the
basis of ecore models. I also incorporated the idea of using annotations to hint to the generator
(the templates really, what you call the engine I think) which ui-controls to generate for specific
efeatures. This because the domain model in itself does often not contain enough information to make
sensible choices in the templates.
Earlier this week I created a proposal for generating web apps with ui's on the basis of ecore
models and ui-annotations:
http://wiki.eclipse.org/texo
I posted the proposal on various eclipse newsgroups, hopefully this can become an EMFT project.
Would it be possible/are you interested to share the current set of ui-annotations you have? The
ones I have can be found in the proposal above.
For the rest I am very much in favor for more tooling support for maintaining annotations in a more
structured way in model editors. Like what you tested for generating your own editor.
Another group of people is looking at creating a ui-model which allows you to model ui's in a more
structured way. Afaik the idea is to do as a project this within the eclipse modeling project
(correct Ed?).
gr. Martin
Michael Scharf wrote:
> Hi Jonas,
>
> this project was a typical "Teflon Project"[1].
>
> I put it together in a relatively short time and
> it was great do demo. We have also build some
> products on top. Unfortunately, my management
> did not understand the value of the project
> (although I played all the tricks of a Teflon-programmer)
> and now is has been degraded from generic solution
> for a range of problems to a specific solution
> for one particular project.
>
> The sad side of the story is that inside my company
> there is the mis-perception that the generic editor is
> huge and complicated. And this comes mainly from the
> fact that I use EMF and the underlying data model.
> And because EMF dragged in a lot of other plugins [2]
> at that time, the perception was that my framework
> is heavyweight (because the all of emf including
> JDT were seen as part of my framework).
>
> Ironically nobody wants to use my "heavy wight" framework,
> and therefore many new frameworks were written implementing
> their own (incomplete) version of EMF. One of those "lightweight"
> UI frameworks that was created is 10 times bigger than my code
> (if you don't count EMF as part of the generic editor).
>
> We are still working on the generic editor
> as part of the project it has been confined to in the hope
> to put it into the light when its time has come....
>
> At the moment we are not working on the UI part of the
> framework, but on the infrastructure needed for that
> particular project. But in the not to far future we want
> to refactor/rewrite the generic UI part. Maybe we join
> our forces with the OAW generic editor.
>
> As shown in the presentation, I decided to use annotations
> to drive the UI. We call those annotations UIHints, because
> they give a hint to the renderer how to display the properties
> in the UI. I deliberately chose the term "hint" because the
> ui-engine might decide to ignore some hints. It is like
> HTML in the old days, where you specified this is a header,
> or emphasized and the html browser does the layout for you
> (or like LaTex).
>
> This project started 4 years ago, at that time there was
> noting like OCL available for EMF. But to do the UI, you
> also need validation and some basic form of enable/disable
> support for controls. I had written a tiny expression
> evaluator based on OQL [3]. With OQL the user can specify
> disablement of attributes as well as validation.
>
> Today I'd use CQL [4] or openArchitectureWare Check [5].
>
> I addition, I created my own incarnation of databinding [6],
> because it was not available at that time.
>
> Unfortunately, the weakest part of our generic editor is
> the engine that interprets the UIHints and turns it into
> the UI. It started as a very small set of hints and the
> number of hint grew but I did not have time to refactor
> the engine, although I have some ideas hoe I'd do it.
>
> I think it would be great if we could put all the different
> efforts together and create a solid data-driven UI.
>
> Note: although we use EMF annotations for the UIHints there is
> nothing that prevents us from absrtacting this out. All you
> need is to get the UI hints for a given element:
> UIHint[] HintAdapter.getHints(Object object)
>
> Note 2: one other obvious idea is to extend emfatic [8] to make
> the annotations have a Metamodel. Now annotations are free-form.
> When you have a metamodel for annotations you can create an
> text editor that (using TMF [7]). We did some experiments using
> xText [9] to create our own version of emfatic.
>
> I think the biggest contribution I can make is to share my
> experience, the good and the bad decisions we made on our
> generic editor (I switch here between "my" and "our" framework,
> because most of the design and implementation was done by
> me with Anton Leherbauer contributing some of the initial
> UIHint engine and doing some bug fixing and Richard Memory
> working right now on the framework)
>
>
>
> Michael
>
> [1] http://ed-merks.blogspot.com/2008/04/teflon-programming.html
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=106804
> [3] http://en.wikipedia.org/wiki/Object_Query_Language
> [4] http://www.eclipse.org/modeling/mdt/?project=ocl#ocl
> [5]
> http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/core_re ference.html
> [6] http://wiki.eclipse.org/index.php/JFace_Data_Binding
> [7] http://www.eclipse.org/proposals/tmf/
> [8]
> http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/using_t he_emfatic_ecore_editor.html
>
> [9]
> http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/xtext_r eference.html
>
>> Thank you Ed for moving the post and sorry, i am quite new to the
>> community...
>>
>>> It's best to ask EMF questions on the EMF newsgroup, which I've added
>>> to the "to" list of the reply.
>>
>> http://scharf.gr/eclipse/eclipsecon2006/Unconventional_but_S imple_Annotations_to_Customize_EMF_Editors/
>>
>>
>> Do you have any idea how to get in contact with michael or which
>> project he is working on? the presentation looks very promising.
>>
>>
>>
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Generic form editor for EMF EObjects [message #327155 is a reply to message #327154] |
Fri, 11 April 2008 17:48 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Martin,
Yes, I expect Jim van Dam and Yves Yang to create a project proposal...
Martin Taal wrote:
> Hi Michael,
> Interesting that you use UIHints. I have been working for a few months
> on generating web ui's on the basis of ecore models. I also
> incorporated the idea of using annotations to hint to the generator
> (the templates really, what you call the engine I think) which
> ui-controls to generate for specific efeatures. This because the
> domain model in itself does often not contain enough information to
> make sensible choices in the templates.
>
> Earlier this week I created a proposal for generating web apps with
> ui's on the basis of ecore models and ui-annotations:
> http://wiki.eclipse.org/texo
>
> I posted the proposal on various eclipse newsgroups, hopefully this
> can become an EMFT project.
>
> Would it be possible/are you interested to share the current set of
> ui-annotations you have? The ones I have can be found in the proposal
> above.
>
> For the rest I am very much in favor for more tooling support for
> maintaining annotations in a more structured way in model editors.
> Like what you tested for generating your own editor.
>
> Another group of people is looking at creating a ui-model which allows
> you to model ui's in a more structured way. Afaik the idea is to do as
> a project this within the eclipse modeling project (correct Ed?).
>
> gr. Martin
>
> Michael Scharf wrote:
>> Hi Jonas,
>>
>> this project was a typical "Teflon Project"[1].
>>
>> I put it together in a relatively short time and
>> it was great do demo. We have also build some
>> products on top. Unfortunately, my management
>> did not understand the value of the project
>> (although I played all the tricks of a Teflon-programmer)
>> and now is has been degraded from generic solution
>> for a range of problems to a specific solution
>> for one particular project.
>>
>> The sad side of the story is that inside my company
>> there is the mis-perception that the generic editor is
>> huge and complicated. And this comes mainly from the
>> fact that I use EMF and the underlying data model.
>> And because EMF dragged in a lot of other plugins [2]
>> at that time, the perception was that my framework
>> is heavyweight (because the all of emf including
>> JDT were seen as part of my framework).
>>
>> Ironically nobody wants to use my "heavy wight" framework,
>> and therefore many new frameworks were written implementing
>> their own (incomplete) version of EMF. One of those "lightweight"
>> UI frameworks that was created is 10 times bigger than my code
>> (if you don't count EMF as part of the generic editor).
>>
>> We are still working on the generic editor
>> as part of the project it has been confined to in the hope
>> to put it into the light when its time has come....
>>
>> At the moment we are not working on the UI part of the
>> framework, but on the infrastructure needed for that
>> particular project. But in the not to far future we want
>> to refactor/rewrite the generic UI part. Maybe we join
>> our forces with the OAW generic editor.
>>
>> As shown in the presentation, I decided to use annotations
>> to drive the UI. We call those annotations UIHints, because
>> they give a hint to the renderer how to display the properties
>> in the UI. I deliberately chose the term "hint" because the
>> ui-engine might decide to ignore some hints. It is like
>> HTML in the old days, where you specified this is a header,
>> or emphasized and the html browser does the layout for you
>> (or like LaTex).
>>
>> This project started 4 years ago, at that time there was
>> noting like OCL available for EMF. But to do the UI, you
>> also need validation and some basic form of enable/disable
>> support for controls. I had written a tiny expression
>> evaluator based on OQL [3]. With OQL the user can specify
>> disablement of attributes as well as validation.
>>
>> Today I'd use CQL [4] or openArchitectureWare Check [5].
>>
>> I addition, I created my own incarnation of databinding [6],
>> because it was not available at that time.
>>
>> Unfortunately, the weakest part of our generic editor is
>> the engine that interprets the UIHints and turns it into
>> the UI. It started as a very small set of hints and the
>> number of hint grew but I did not have time to refactor
>> the engine, although I have some ideas hoe I'd do it.
>>
>> I think it would be great if we could put all the different
>> efforts together and create a solid data-driven UI.
>>
>> Note: although we use EMF annotations for the UIHints there is
>> nothing that prevents us from absrtacting this out. All you
>> need is to get the UI hints for a given element:
>> UIHint[] HintAdapter.getHints(Object object)
>>
>> Note 2: one other obvious idea is to extend emfatic [8] to make
>> the annotations have a Metamodel. Now annotations are free-form.
>> When you have a metamodel for annotations you can create an
>> text editor that (using TMF [7]). We did some experiments using
>> xText [9] to create our own version of emfatic.
>>
>> I think the biggest contribution I can make is to share my
>> experience, the good and the bad decisions we made on our
>> generic editor (I switch here between "my" and "our" framework,
>> because most of the design and implementation was done by
>> me with Anton Leherbauer contributing some of the initial
>> UIHint engine and doing some bug fixing and Richard Memory
>> working right now on the framework)
>>
>>
>>
>> Michael
>>
>> [1] http://ed-merks.blogspot.com/2008/04/teflon-programming.html
>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=106804
>> [3] http://en.wikipedia.org/wiki/Object_Query_Language
>> [4] http://www.eclipse.org/modeling/mdt/?project=ocl#ocl
>> [5]
>> http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/core_re ference.html
>> [6] http://wiki.eclipse.org/index.php/JFace_Data_Binding
>> [7] http://www.eclipse.org/proposals/tmf/
>> [8]
>> http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/using_t he_emfatic_ecore_editor.html
>>
>> [9]
>> http://www.eclipse.org/gmt/oaw/doc/4.2/html/contents/xtext_r eference.html
>>
>>
>>> Thank you Ed for moving the post and sorry, i am quite new to the
>>> community...
>>>
>>>> It's best to ask EMF questions on the EMF newsgroup, which I've
>>>> added to the "to" list of the reply.
>>>
>>> http://scharf.gr/eclipse/eclipsecon2006/Unconventional_but_S imple_Annotations_to_Customize_EMF_Editors/
>>>
>>>
>>> Do you have any idea how to get in contact with michael or which
>>> project he is working on? the presentation looks very promising.
>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: Generic form editor for EMF EObjects [message #327187 is a reply to message #327149] |
Sun, 13 April 2008 17:19 |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Hi Michael,
thank you for your detailed answer. ItŽs more an article then a news group
post. :-)
> this project was a typical "Teflon Project"[1].
> We are still working on the generic editor
> as part of the project it has been confined to in the hope
> to put it into the light when its time has come....
ThatŽs a sad story of missunderstanding. Do i understand it correct that
the project has never been open source? Is that what you mean with
"putting it into the light"?
> As shown in the presentation, I decided to use annotations
> to drive the UI. We call those annotations UIHints, because
> they give a hint to the renderer how to display the properties
> in the UI. I deliberately chose the term "hint" because the
> ui-engine might decide to ignore some hints. It is like
> HTML in the old days, where you specified this is a header,
> or emphasized and the html browser does the layout for you
> (or like LaTex).
I like the term "UIHints". I my old application we saved the UIHints in
property files, but annotations seem to be more maintainable as the are
integrated into the model. As i understood it the annotations are also
bound to the according feature object?
Are there any problems if you use dynamic instances of emf?
> I addition, I created my own incarnation of databinding [6],
> because it was not available at that time.
I am not sure if i am going to use databindings. As i understood it the
implementation for EMF are not finished. Can i use databindings together
with commands?
> I think it would be great if we could put all the different
> efforts together and create a solid data-driven UI.
Hmm, i guess it could be hard to consolidate different application
domains. For my application i would say that the number of UIHints can be
quite low. Our focus is not to create very complex UIŽs but to provide
dynamically generated editors for model elements in a unified layout and
look. The meta-model can change over the application life time.
This is how we did it in our old application:
every attribute was described with some basic UIHints like:
-Type: the widget to display and edit the attribute. We had a number of
widgets like link editors or text-areas, which also implemented the
databinding. So they are a little bit more then the eclipse.ui.widgets. Do
you know sth. like this, for example a widget to edit a N:N reference with
add and remove buttons?
-Label
-Tab
-Editable
-Optional
and so on...
Additional every element type had a list of all the displayed attributes
to determine the order of the attributes.
The UI was created on runtime based on this information using a factory
which created the widgets. Then the were put together on a form. Does your
approach work sh. like this?
> Note: although we use EMF annotations for the UIHints there is
> nothing that prevents us from absrtacting this out. All you
> need is to get the UI hints for a given element:
> UIHint[] HintAdapter.getHints(Object object)
Definitly!
> Note 2: one other obvious idea is to extend emfatic [8] to make
> the annotations have a Metamodel. Now annotations are free-form.
> When you have a metamodel for annotations you can create an
> text editor that (using TMF [7]). We did some experiments using
> xText [9] to create our own version of emfatic.
Sound like a good idea, i will have a look at this.
|
|
|
| Re: Generic form editor for EMF EObjects [message #327189 is a reply to message #327187] |
Sun, 13 April 2008 19:17 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jonas,
The org.eclipse.emf.databinding.edit plugins available in EMF 2.4 will
make all changes to the model using command and are hence undoable. It
should work well, but if anything isn't, I'll fix the problems promptly.
Jonas wrote:
> Hi Michael,
> thank you for your detailed answer. ItŽs more an article then a news
> group post. :-)
>
>> this project was a typical "Teflon Project"[1].
>
>> We are still working on the generic editor
>> as part of the project it has been confined to in the hope
>> to put it into the light when its time has come....
>
> ThatŽs a sad story of missunderstanding. Do i understand it correct
> that the project has never been open source? Is that what you mean
> with "putting it into the light"?
>
>> As shown in the presentation, I decided to use annotations
>> to drive the UI. We call those annotations UIHints, because
>> they give a hint to the renderer how to display the properties
>> in the UI. I deliberately chose the term "hint" because the
>> ui-engine might decide to ignore some hints. It is like
>> HTML in the old days, where you specified this is a header,
>> or emphasized and the html browser does the layout for you
>> (or like LaTex).
>
> I like the term "UIHints". I my old application we saved the UIHints
> in property files, but annotations seem to be more maintainable as the
> are integrated into the model. As i understood it the annotations are
> also bound to the according feature object?
> Are there any problems if you use dynamic instances of emf?
>
>> I addition, I created my own incarnation of databinding [6],
>> because it was not available at that time.
>
> I am not sure if i am going to use databindings. As i understood it
> the implementation for EMF are not finished. Can i use databindings
> together with commands?
>
>> I think it would be great if we could put all the different
>> efforts together and create a solid data-driven UI.
>
> Hmm, i guess it could be hard to consolidate different application
> domains. For my application i would say that the number of UIHints can
> be quite low. Our focus is not to create very complex UIŽs but to
> provide dynamically generated editors for model elements in a unified
> layout and look. The meta-model can change over the application life
> time.
>
> This is how we did it in our old application:
> every attribute was described with some basic UIHints like:
> -Type: the widget to display and edit the attribute. We had a number
> of widgets like link editors or text-areas, which also implemented
> the databinding. So they are a little bit more then the
> eclipse.ui.widgets. Do you know sth. like this, for example a widget
> to edit a N:N reference with add and remove buttons?
>
>
> -Label -Tab
> -Editable
> -Optional
>
> and so on...
> Additional every element type had a list of all the displayed
> attributes to determine the order of the attributes.
>
> The UI was created on runtime based on this information using a
> factory which created the widgets. Then the were put together on a
> form. Does your approach work sh. like this?
>
>> Note: although we use EMF annotations for the UIHints there is
>> nothing that prevents us from absrtacting this out. All you
>> need is to get the UI hints for a given element:
>> UIHint[] HintAdapter.getHints(Object object)
>
> Definitly!
>
>> Note 2: one other obvious idea is to extend emfatic [8] to make
>> the annotations have a Metamodel. Now annotations are free-form.
>> When you have a metamodel for annotations you can create an
>> text editor that (using TMF [7]). We did some experiments using
>> xText [9] to create our own version of emfatic.
>
> Sound like a good idea, i will have a look at this.
>
>
>
>
>
|
|
| |
| Re: Generic form editor for EMF EObjects [message #327223 is a reply to message #327221] |
Mon, 14 April 2008 12:29 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------060308040005000705070103
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Jonas,
These should be present...
eclipse/plugins/org.eclipse.emf.databinding.edit_1.0.0.v2008 04012208.jar
eclipse/plugins/org.eclipse.emf.databinding_1.0.0.v200804012 208.jar
Jonas wrote:
> Hi
> i ve EMF 2.4 installed, but i couldn
|
|
| | | |
| Re: Generic form editor for EMF EObjects [message #327307 is a reply to message #327303] |
Tue, 15 April 2008 12:34 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Nick,
Could you please verify that these things (the two new data binding
plugins and their features) are getting onto the update site and that I
didn't screw something up when I added these new plugins.
Jonas wrote:
> Thank you that worked for me. But i had to copy the jars manually.
> Even with local update site, i couldnŽt install them using the update
> manager.
>
|
|
|
| Re: Generic form editor for EMF EObjects [message #327370 is a reply to message #327307] |
Wed, 16 April 2008 16:43 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jonas,
Nick opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=227376 to fix
my oversight that resulted in the features not being include and hence
these plugins not being available with the update manager.
Ed Merks wrote:
> Nick,
>
> Could you please verify that these things (the two new data binding
> plugins and their features) are getting onto the update site and that
> I didn't screw something up when I added these new plugins.
>
>
> Jonas wrote:
>> Thank you that worked for me. But i had to copy the jars manually.
>> Even with local update site, i couldnŽt install them using the update
>> manager.
>>
|
|
| |
Goto Forum:
Current Time: Fri Dec 27 13:55:03 GMT 2024
Powered by FUDForum. Page generated in 0.33809 seconds |
] 
Search
Help
Register
Login
Home
