[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] p2, authoring, and EMF?
- From: "Chris Aniszczyk" <caniszczyk@xxxxxxxxx>
- Date: Thu, 4 Sep 2008 10:55:18 -0500
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=T/hE5rUOqRIuMIWvMUJbHvcUuw6Q22w+kGGUzHyS3Cn6ZTd/+DcM8iXskwmMAL9g0C epveUCiGFgs8A5yr/ZTrphj93p4aiYqv+kFGzk8MZu5mKzxoDnCMm4X33NTWNUmX5uyK 3KP5LhWdfx/emk2gKFrsP8h4aHDnKgwiCpPZI=
Obviously I'm interested in this topic Benjamin. If I have to write another PDE editor with a boilerplate model I may go crazy.
The question here is do we want to start experimenting with this somewhere, like the PDE incubator? I would love to see the effort of using EMF/Databinding to simplify the creation of editors. If noone from p2 objects, I will start working with Benjamin with this in the PDE incubator to see how far we can take it.
On Thu, Sep 4, 2008 at 4:06 AM, Benjamin CABÃ <benjamin.cabe@xxxxxxxxxxxxxxxx>
Is nobody interested in this topic ? :-)
Benjamin CABÃ a Ãcrit :
We've made some further work on the "p2 authoring tools" and developed
an early prototype of a metadata repository editor, which is quite
similar to what the "Update site editor" proposes.
A requirement document has been initialized on the wiki
We'd like to have some feedback from the p2 community about the choice
we made to use an EMF model behind the editor, to ease the GUI
development (databinding, EMF content & label providers, undo/redo,
...). This model is very close to the p2 API (see attached class
At the moment, what we've done is to bind the editor to our metadata
repository "EObject", and propose a "content.xml export" action that
converts our EMF model to p2 API classes. This is something very
trivial, and that works well, *but* we think it would be great to think
about having the p2 engine directly available as an EMF API.
Some work has already been done to make EMF Core, Edit, and Edit.UI
Foundation 1.1 compatible (see bug #215378) ; and the discussion about
more EMF inside e4 (e.g. an EMF workbench model) came to the
that EMF is kind of great and can keep a very tiny footprint.
In the p2 context, having an EMF model would allow :
From what we have seen, most of the p2 API
IInstallableUnit, ...) have implementations that are quite
straightforward (getters and setters directly bound to their underlying
attribute), and the constructors could easily be replaced by the EMF
- more trivial XML
- listening to model changes
- UI writing simplified (a lot!)
- Treeviewers, labelproviders, etc.
much simpler using the
What do you, p2 gurus, think about having more EMF in p2? Is it
something that has already been discussed?
p2-dev mailing list
p2-dev mailing list
~ Chris Aniszczyk