Home » Modeling » EMF » EMF usability improvement
| EMF usability improvement [message #1692813] |
Sun, 19 April 2015 17:45  |
|
Hi modelers!
I've been using EMF for quite a long time now, and here's some kind of improvements I'm thinking to makes it more user-friendly.
All along this post, I'll take a simple MetaModel sample in order to try to explain the purpose:
Let's take a company metamodel containing:
A CompanyPKG root element with containment relation to 'Person'
This 'Person' have a 'name' attribute, and also a getAddress method
Let's have a 'Developper' that inherits from a 'Person'
* About genmodels
* * Defaulting generation to src-gen is IMO one thing to do, but it implies some improvements
* * * suffixing implementation names by 'Gen' (i.e. PersonImplGen)
* * * generating stubs in the src folder (PersonImpl extends PersonImplGen)
* * * making inheritance chains from XImplGen to XImpl so that 'DevelopperImplGen' would inherit from 'PersonImpl'
* * the child extender and extensible factories should always be true: Who cares?
This would allow method override far more simpler for the end user (no more @was generated or @generated NOT), content of src-gen will always be discarded at each generation, while content of src will never be
* * XMI gen:
* * * always generating a functional ID, always generating it, always referencing using UUID: this would avoid MANY issues (merge, copy).
* * * In the ecore/genmodel, always referencing elements with platform:/resource styled URIs even if they are internals (i.e. in the 'company.ecore', having the 'person' class generated as class="platform:/resource/company/company#Person" instead of "#Person") .
That would allow external/internal reference expressed the same way.
* * Framework itself
* * * no distinction between plt/resource, plt/plugin URIs: the framework itself should be using delegation chain to do it (and it does already).
* * * adapter should be renamed 'observers' (it's santa's which, isn't it? ^^).
* * * don't mix DAOs and Entity concepts (X.eAdapters, X.eContainer, etc... should be moved to a XDao.getEAdapter(myEntity))
* * * XML (or file) should not be the default target, an embedded database (in mem or flat file like derby) should be: it would improve EMF/CDO cohabitation and leverage implementation to a better scalable result.
* * * EMF jet patterns should have many more injection points
* * Setters (and even factory) should be deprecated in favor of using edit commands
* About Edit
* * Same remark for src-gen/src generation (and even for .editor) as the one for genmodels
* * Icons and texts should be inherited from their parents if customized (a developper icon must be the one of its parent if its one isn't customized)
* About UI/UX
* * A 'generate UI' should be nice, generating EEF, EMF form, PMF property views
* * Type selection would be better with an Xtext input than with the combobox one
* * A generate Diagram too  (with Sirius?)
* * Drag and drop between editors, copy/cut/paste between editors, etc could be far more improved
* * Generation wizard should also generate an ecore diagrams
* * navigation from model element to its subclas could be done via a shortcut/context menu
* * providing bridges from model to generated/overriden code could be a nice addition
* * project creation wizards can be improved (empty emf project then creating an ecore) (reload resource)
* * creating a project wizard for each editor could be a nice thing also (not just a 'X model' wizard)
* About CDO
I'll be more acid on this part as I'm coming from the J2EE world
* * Net4j: really? Why not using standards like JMS? JMS support intra VM notif and also distant ones, queues/topics, brokers linking, etc... There's also DOSGI that provides centralized service handling, node replication, etc for free (Eike, don't you dream about running CDO on 20K node cluster?). Finally, elements URI can be explained as JMS destination queues.
* * EMF Transactions? What about JTA, nested transactions and a simple Memento pattern?
* * locks are also a JTA/JPA concern...
* * Containments, etc... could just be generated as JPA @Cascade
* * Command (.edit) could generate a JSON REST service: editor is client side, model and edit server side
* * So for every (most of) CDO homebaked concepts, there are a J2EE equivalent, why not using them?
* * Database should use JPA by default (and use it right, not a select per child while calling eAllContainment).
In my point of view, CDO should be a J2EE-like generation of Java-like (fat client) EMF one.
EMF is now an enterprise standard for modeling, so it should leverage in term of usability: nowadays only EMF developers (e.g. specialists) can use it because of these UX/dev lacks, and they could be easily improved (we're plenty of developers wanting to contribute if you want) with some little API breaks and model-to-model bridges for the ones who want to upgrade.
Don't think that I'm not happy with EMF/CDO that are a very good frameworks, I'm just seeing some improvement points.
Best regards,
Charlie
|
|
|
| Re: EMF usability improvement [message #1692821 is a reply to message #1692813] |
Mon, 20 April 2015 00:20  |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
On 19.04.2015 19:45, Charlie Mordant wrote:
> Hi modelers!
>
> I've been using EMF for quite a long time now, and here's some kind of
> improvements I'm thinking to makes it more user-friendly.
>
> All along this post, I'll take a simple MetaModel sample in order to try
> to explain the purpose:
>
> Let's take a company metamodel containing:
> A CompanyPKG root element with containment relation to 'Person'
> This 'Person' have a 'name' attribute, and also a getAddress method
> Let's have a 'Developper' that inherits from a 'Person'
>
>
> * About genmodels
> * * Defaulting generation to src-gen is IMO one thing to do, but it
> implies some improvements
That's what an Xcore specified model will do, but I'm personally not a
fan of that approach, and I'm generally the one who has to do all the
work to maintain every variation that strikes someone's fancy:
http://ed-merks.blogspot.com/2008/10/hand-written-and-generated-code-never.html
> * * * suffixing implementation names by 'Gen' (i.e. PersonImplGen)
> * * * generating stubs in the src folder (PersonImpl extends PersonImplGen)
> * * * making inheritance chains from XImplGen to XImpl so that
> 'DevelopperImplGen' would inherit from 'PersonImpl'
> * * the child extender and extensible factories should always be true:
> Who cares?
It certainly affects existing models, but one could definitely
initialize newly created models with better defaults, so that's
something to consider...
> This would allow method override far more simpler for the end user (no
> more @was generated or @generated NOT), content of src-gen will always
> be discarded at each generation, while content of src will never be
>
As I suggested above, having twice as many classes doesn't strike me as
simpler.
> * * XMI gen:
> * * * always generating a functional ID, always generating it, always
> referencing using UUID: this would avoid MANY issues (merge, copy).
Absolutely not. This is a modeler's choice and, for example, not what
Ecore itself does.
> * * * In the ecore/genmodel, always referencing elements with
> platform:/resource styled URIs even if they are internals (i.e. in the
> 'company.ecore', having the 'person' class generated as
> class="platform:/resource/company/company#Person" instead of "#Person") .
> That would allow external/internal reference expressed the same way.
This makes no sense to me. Why should an reference within the same
resource specify the name of the resource?
>
> * * Framework itself
> * * * no distinction between plt/resource, plt/plugin URIs: the
> framework itself should be using delegation chain to do it (and it does
> already).
One is for things in the workspace and the other is for things in
installed bundles. There is a semantic difference. One can't just wish
it away, and certainly can't change it after the fact.
> * * * adapter should be renamed 'observers' (it's santa's which, isn't
> it? ^^).
You've got to be kidding> We'll just rename all the classes, break
everyone's APIs, and rewrite the book...
> * * * don't mix DAOs and Entity concepts (X.eAdapters, X.eContainer,
> etc... should be moved to a XDao.getEAdapter(myEntity))
And somehow maintain binary compatibility?
> * * * XML (or file) should not be the default target, an embedded
> database (in mem or flat file like derby) should be: it would improve
> EMF/CDO cohabitation and leverage implementation to a better scalable
> result.
Oh my goodness...
> * * * EMF jet patterns should have many more injection points
>
>
> * * Setters (and even factory) should be deprecated in favor of using
> edit commands
It just gets worse. Everyone should use commands even when they don't
intend to build a UI...
>
> * About Edit
> * * Same remark for src-gen/src generation (and even for .editor) as the
> one for genmodels
> * * Icons and texts should be inherited from their parents if customized
> (a developper icon must be the one of its parent if its one isn't
> customized)
>
> * About UI/UX
> * * A 'generate UI' should be nice, generating EEF, EMF form, PMF
> property views
> * * Type selection would be better with an Xtext input than with the
> combobox one
> * * A generate Diagram too :) (with Sirius?)
> * * Drag and drop between editors, copy/cut/paste between editors, etc
> could be far more improved
> * * Generation wizard should also generate an ecore diagrams
> * * navigation from model element to its subclas could be done via a
> shortcut/context menu
> * * providing bridges from model to generated/overriden code could be a
> nice addition
> * * project creation wizards can be improved (empty emf project then
> creating an ecore) (reload resource)
> * * creating a project wizard for each editor could be a nice thing also
> (not just a 'X model' wizard)
I'm getting exhausted just reading all this...
>
> * About CDO
> I'll be more acid on this part as I'm coming from the J2EE world
> * * Net4j: really? Why not using standards like JMS? JMS support intra
> VM notif and also distant ones, queues/topics, brokers linking, etc...
> There's also DOSGI that provides centralized service handling, node
> replication, etc for free (Eike, don't you dream about running CDO on
> 20K node cluster?). Finally, elements URI can be explained as JMS
> destination queues.
> * * EMF Transactions? What about JTA, nested transactions and a simple
> Memento pattern?
> * * locks are also a JTA/JPA concern...
> * * Containments, etc... could just be generated as JPA @Cascade
> * * Command (.edit) could generate a JSON REST service: editor is client
> side, model and edit server side
> * * So for every (most of) CDO homebaked concepts, there are a J2EE
> equivalent, why not using them?
> * * Database should use JPA by default (and use it right, not a select
> per child while calling eAllContainment).
> In my point of view, CDO should be a J2EE-like generation of Java-like
> (fat client) EMF one.
>
> EMF is now an enterprise standard for modeling, so it should leverage in
> term of usability: nowadays only EMF developers (e.g. specialists) can
> use it because of these UX/dev lacks, and they could be easily improved
> (we're plenty of developers wanting to contribute if you want) with some
> little API breaks and model-to-model bridges for the ones who want to
> upgrade.
>
> Don't think that I'm not happy with EMF/CDO that are a very good
> frameworks, I'm just seeing some improvement points.
More than can possibility be accommodated. One of EMF's key value
points is binary compatibility for 10 years. And while people have
brainstormed EMF 3.0, it's essentially infeasible to break binary
compatibility. The only real option is to create a new EMF with new
namespaces that coexists with the old EMF. That's certainly way beyond
the one man team's capacity...
>
> Best regards,
>
> Charlie
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF usability improvement [message #1692841 is a reply to message #1692813] |
Mon, 20 April 2015 07:41 |
|
Hi Ed,
Thank you fr your answers.
As I understand, keeping compatibility is the main concern (and yes, this kind of improvement would lead to an EMF 3).
Is there anybody that started EMF3? A git repo somewhere?
Regards,
|
|
|
| Re: EMF usability improvement [message #1692879 is a reply to message #1692841] |
Mon, 20 April 2015 11:48 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
EMF is not perfect, but it is very useful and has an ever increasing
number of extensions each of which will need rework by a successor.
IMHO there is no point in EMF 3 unless a large very well-resource
company/team commits to it and many of its extensions with a vengeance.
As automation gets better and better, e.g. Xtext, Xbase, the
imperfections of EMF are better hidden.
You will do much better to look towards more automation, or enhanced UI
facades.
Regards
Ed Willink
On 20/04/2015 08:41, Charlie Mordant wrote:
> Hi Ed,
>
> Thank you fr your answers.
> As I understand, keeping compatibility is the main concern (and yes,
> this kind of improvement would lead to an EMF 3).
>
> Is there anybody that started EMF3? A git repo somewhere?
>
> Regards,
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 21:33:12 GMT 2024
Powered by FUDForum. Page generated in 0.03145 seconds |
] 
Search
Help
Register
Login
Home
