EMF und Notification Framework

Bitte aktiviere JavaScript!
G

Gast2

Vielleicht nochmal eine kleine Frage.

Gibt es auch was wo EMF einen Eingabe Editoren (Masken) erstellt?
Also das nicht alles in einem Baum dargestellt wird sondern, alle Attribute mit Label und Textfeldern wie in der PropertView?
z.B. Person(name,vorname)

Editor

label textfeld(name)
label textfeld(vorname)
 
Du meinst aber explizit in nicht in der Properties View, sondern in zB einem Dialog oder einer Eclipse Forms Section?
Jein. Es gibt EEF das die default Properties View durch eine Forms basierte ersetzt und dabei auch gleich Wizards/Dialoge mit der gleichen Funktionalität produziert.
Dann gibt es noch den Generic EMF Editor der ebenfalls die Properties View durch eine Forms basierte Tabbed Properties View ersetzt, allerdings ohne dabei Code zu generieren.
EEF ist IMO noch zu sehr incubation und der Generic EMF Editor verwendet wie gesagt die Properties View.
Aber: du kannst dir die Technik des Generic EMF Editors zu nutze machen um automatisch aus den EClasses Forms ausserhalb der Properties View zu instanzieren. Wenn du bereit bist selbst etwas Arbeit zu investieren ist es mit EMF auch sehr einfach dir ein solches Framework selbst zu schreiben.
Du kannst problemlos alle Features einer EClass und deren Typ auslesen und aus dieser Information Widgets erstellen und mit Databinding Verknüpfen. Wenn du zusätzliche Informationen wie Labels oder Gruppierungsinformationen haben möchtest, kannst du EAnnotations in dein Ecore einfügen.
Dadurch das dein Modell explizit im Ecore bekannt ist lässt sich soetwas sehr leicht programmieren.

Auf die Schnelle habe ich zB dieses Beispiel gefunden:
http://www.conceptualprocessengineering.com/library/
 
G

Gast2

Du meinst aber explizit in nicht in der Properties View, sondern in zB einem Dialog oder einer Eclipse Forms Section?
Jein. Es gibt EEF das die default Properties View durch eine Forms basierte ersetzt und dabei auch gleich Wizards/Dialoge mit der gleichen Funktionalität produziert.
Dann gibt es noch den Generic EMF Editor der ebenfalls die Properties View durch eine Forms basierte Tabbed Properties View ersetzt, allerdings ohne dabei Code zu generieren.
EEF ist IMO noch zu sehr incubation und der Generic EMF Editor verwendet wie gesagt die Properties View.
Aber: du kannst dir die Technik des Generic EMF Editors zu nutze machen um automatisch aus den EClasses Forms ausserhalb der Properties View zu instanzieren. Wenn du bereit bist selbst etwas Arbeit zu investieren ist es mit EMF auch sehr einfach dir ein solches Framework selbst zu schreiben.
Du kannst problemlos alle Features einer EClass und deren Typ auslesen und aus dieser Information Widgets erstellen und mit Databinding Verknüpfen. Wenn du zusätzliche Informationen wie Labels oder Gruppierungsinformationen haben möchtest, kannst du EAnnotations in dein Ecore einfügen.
Dadurch das dein Modell explizit im Ecore bekannt ist lässt sich soetwas sehr leicht programmieren.

Auf die Schnelle habe ich zB dieses Beispiel gefunden:
http://www.conceptualprocessengineering.com/library/
Ja ich sollte erst einmal genauer EMF lernen ;), bevor ich an sowas denke.
Aber war neugierig ob es sowas schon gibt. Aber des EEF wäre ja schon mal ein Ansatz ein paar Sachen verwenden zu können.
Besser wie grad alles mit händisch + databinding zu machen ;). Aber da ich nur am versuchen und lernen bin ist es nicht schlimm.
Muss auch sagen dass es mit ein paar eigenen Klasse und Factory methoden nicht viel Code ist einen Editor + Databinding zu machen. Undo/Redo sind ja auch gleich dabei.
Aber danke für die infos.
 
Wie gesagt, es ist sehr einfach Code zu schreiben der aus den Definitionen in EClasses automatisch Widgets instanziert und diese Widgets dann per Databinding an passende EObjects bindet. Primär Fleißarbeit, eine Fingerübung... ich würde davon ausgehen das entweder EEF bald entsprechend mature wird, oder jemand anders ein entsprechendes Projekt vorantreibt. Wenn du selbst so etwas haben willst und dich dabei auf die für dich relevanten Use-Cases beschränkst schafft man das an einem Abend, inklusive Validierung und Field Decorations.
Wenn du dann noch das WidgetToolkit für Forms subclassed kannst du sogar den 'Style' der erzeugten Widgets on-the-fly ändern, also zB wahlweise Eclipse Forms oder Plain Widgets mit grauem Hintergrund erzeugen.
 
G

Gast2

Wie gesagt, es ist sehr einfach Code zu schreiben der aus den Definitionen in EClasses automatisch Widgets instanziert und diese Widgets dann per Databinding an passende EObjects bindet. Primär Fleißarbeit, eine Fingerübung... ich würde davon ausgehen das entweder EEF bald entsprechend mature wird, oder jemand anders ein entsprechendes Projekt vorantreibt. Wenn du selbst so etwas haben willst und dich dabei auf die für dich relevanten Use-Cases beschränkst schafft man das an einem Abend, inklusive Validierung und Field Decorations.
Wenn du dann noch das WidgetToolkit für Forms subclassed kannst du sogar den 'Style' der erzeugten Widgets on-the-fly ändern, also zB wahlweise Eclipse Forms oder Plain Widgets mit grauem Hintergrund erzeugen.
Joa klingt interessant, aber zuerst einmal sollte ich mich noch mit EMF beschäftigen, um alle Möglichkeiten zu kennen ;)
 
G

Gast2

Weißt du wie man das Databinding bei einem TableViewer mit EMF Undo/Redo gescheit macht?
Ich versteh es noch nicht so richtig bei einem Viewer...

Also ich denke ich benötige die Liste von Nodes: Diesen ContentProvider...
Aber weiter fehlt es mir jetzt...

Java:
		ObservableListContentProvider cp =new ObservableListContentProvider();
	IEMFEditListProperty list = EMFEditProperties.list(editingDomain, Package.Literals.NODE__NODES);
		list.
 
Zuletzt bearbeitet von einem Moderator:
G

Gast2

Mhm so hab ich es mal hinbekommen passt zu unserem Beispiel oben wenns mal jemand braucht:

Java:
	final TableViewer viewer = new TableViewer(parent);
	        AdapterFactory factory = new ProvidermodelItemProviderAdapterFactory();
	        viewer.setLabelProvider(new AdapterFactoryLabelProvider(factory));
	        
	        IEMFEditListProperty list = EMFEditProperties.list(editingDomain,ProvidermodelPackage.Literals.NODE__CHILDREN);
			ObservableListContentProvider cp =new ObservableListContentProvider();
			viewer.setContentProvider(cp);
	       
//	        viewer.setContentProvider(new AdapterFactoryContentProvider(factory));
	        final Node root = ProvidermodelFactory.eINSTANCE.createNode();
	        Node child = ProvidermodelFactory.eINSTANCE.createNode();
//	        root.getChildren().add(child);
	        viewer.setInput(list.observe(root));
	        
	        Button button = new Button(parent, SWT.PUSH);
	        button.setText("Add");
	        button.addSelectionListener(new SelectionAdapter() {
	        	@Override
	        	public void widgetSelected(SelectionEvent e) {
	        		
	        		   Command cmd = AddCommand.create(
	 			   	        editingDomain,
	 			   	    root,
	 			   	    ProvidermodelPackage.Literals.NODE__CHILDREN,
	 			   	ProvidermodelFactory.eINSTANCE.createNode());
	        		   System.out.println(cmd.canUndo());
	 			   	      if (cmd.canExecute())
	 			   	      {
	 			   	    	editingDomain.getCommandStack().execute(cmd);
	 			   	      }
//	        		 root.getChildren().add(ProvidermodelFactory.eINSTANCE.createNode());
	        	}
			});
 
Es gibt übrigens auch ein ChangeCommand. Damit kannst du ganz normal auf dem Domain Modell arbeiten (also ohne Commands) und bleibst trotzdem Undo/Redo fähig.
Den ObservableListContentProvider solltest du eigentlich nicht brauchen, der AdapterFactoryContentProvider müsste genügen.
 
G

Gast2

Es gibt übrigens auch ein ChangeCommand. Damit kannst du ganz normal auf dem Domain Modell arbeiten (also ohne Commands) und bleibst trotzdem Undo/Redo fähig.
He? Das ChangeCommand ist doch auch ein Command?
Oder wie führe ich das dann aus?
Meinst du so?
Java:
			ChangeCommand changeCommand = new ChangeCommand(node) {
				
				@Override
				protected void doExecute() {
					node.getNodes().add(newNode);
					
				}
			};
			
			EditingDomain editingDomain = ((EditingDomain) HandlerUtil.getActiveEditor(event))
			.getEditingDomain();
			if (changeCommand.canExecute()) {

				editingDomain.getCommandStack().execute(changeCommand);
			}
Den ObservableListContentProvider solltest du eigentlich nicht brauchen, der AdapterFactoryContentProvider müsste genügen.
Tatsache perfekt =)... Ist ja echt cool dann brauch man ja nur noch eine Zeile
Java:
EMFEditProperties.list(editingDomain,MyPackage.Literals.NODE__NODES);
 
Zuletzt bearbeitet von einem Moderator:
He? Das ChangeCommand ist doch auch ein Command?
Oder wie führe ich das dann aus?
Meinst du so?
Ja, so. Bei einem einfachen Command spielt es keine große Rolle, aber bei komplexeren Operationen ist das Change Command IMO komfortabler als n atomare Commands zu verketten.
 
G

Gast2

Ja, so. Bei einem einfachen Command spielt es keine große Rolle, aber bei komplexeren Operationen ist das Change Command IMO komfortabler als n atomare Commands zu verketten.
Okay.
Was ich noch nicht verstehe ist das ComposedAdapterFactory die geb ich ja dem AdapterFactoryEditingDomain im Konstruktor mit. Und der ComposedAdapterFactory kann ich noch weitere Factory adden. Ich check net ganz für was das gut ist?
 
2 wichtige Gründe:
1. Eine Adapter Factory kann nicht nur die Edit Adapter erstellen, sondern auch Adapter die deinem Modell zB neue Funktionalität verleiht, ähnlich wie IAdaptable in Eclipse. Anstatt nun alle denkbaren Adapter Typen in einer einzigen Factory Bündeln zu müssen kannst du dank der Composed Adapter Factory mehrere verschiedene Adapter Factories implementieren und sie dann alle einer Composed Adapter Factory hinzufügen. Die Composed Adapter Factory unterstützt dann alle Adapter Typen der einzelnen Factories

2. Wenn man sich mit EMF vertraut gemacht hat will man es nicht mehr missen. Man verwendet EMF nun für so ziemlich jede Art Modell in der eigenen Anwendung. Manche dieser Modelle referenzieren wieder andere Modell. Willst du nun zB ein Modell in einem TreeViewer darstellen dessen Kinder wieder aus anderen Modellen kommen dann erlaubt dir die Composed Adapter Factory das du alle benötigten Item Provider in einer einzigen Factory bündelst. Der TreeViewer kann jetzt Objekte aus den unterschiedlichsten Domainen (Ecore Modellen) korrekt rendern ohne die anderen Modelle überhaupt zu 'kennen'.
 
G

Gast2

Okay soweit bin ich wohl noch nicht :)...

2 wichtige Gründe:
1. Eine Adapter Factory kann nicht nur die Edit Adapter erstellen, sondern auch Adapter die deinem Modell zB neue Funktionalität verleiht, ähnlich wie IAdaptable in Eclipse. Anstatt nun alle denkbaren Adapter Typen in einer einzigen Factory Bündeln zu müssen kannst du dank der Composed Adapter Factory mehrere verschiedene Adapter Factories implementieren und sie dann alle einer Composed Adapter Factory hinzufügen. Die Composed Adapter Factory unterstützt dann alle Adapter Typen der einzelnen Factories
Gibt es dazu ne gut Seite ? Wie man durch einen Adapater neue Funktioniltät einem Model gibt?


Aber das hat jetzt nichts mit dem undo/Redo support zu tun oder? Weil ich hab der ComposedAdapterFactory keine weitere Factory hinzugefügt und es klappt trotzdem

Java:
		ComposedAdapterFactory adapterFactory = new ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Registry.INSTANCE);
		BasicCommandStack commandStack = new BasicCommandStack();
		
		editingDomain = new AdapterFactoryEditingDomain(adapterFactory, commandStack, new HashMap<Resource, Boolean>());
 
Zuletzt bearbeitet von einem Moderator:
Aber das hat jetzt nichts mit dem undo/Redo support zu tun oder? Weil ich hab der ComposedAdapterFactory keine weitere Factory hinzugefügt und es klappt trotzdem
Indirekt schon. Du übergibst die globale Registry an die ComposedAdapterFactory. In der Registry sind alle ItemProviderAdapterFactories bekannt die sich per ExtensionPoint anmelden (der per default generierte Edit Code enthält auch eine plugin.xml mit einer solchen Extension).
Wenn nun ein Objekt deines Modells auf einen Item Provider adaptiert werden soll findet die Composed Adapter Factory die passende ItemProviderAdapterFactory über den Extension Point und instanziert sie. Damit werden deine Item Provider verwendet um die Labels, Kinder usw berechnen.
Beim Databinding werden dann die gleichen Item Provider verwendet um Commands zu erzeugen. Diese Commands werden über die Edit Domain ausgeführt und damit funktioniert Undo und Redo.
 
G

Gast2

Indirekt schon. Du übergibst die globale Registry an die ComposedAdapterFactory. In der Registry sind alle ItemProviderAdapterFactories bekannt die sich per ExtensionPoint anmelden (der per default generierte Edit Code enthält auch eine plugin.xml mit einer solchen Extension).
Wenn nun ein Objekt deines Modells auf einen Item Provider adaptiert werden soll findet die Composed Adapter Factory die passende ItemProviderAdapterFactory über den Extension Point und instanziert sie. Damit werden deine Item Provider verwendet um die Labels, Kinder usw berechnen.
Beim Databinding werden dann die gleichen Item Provider verwendet um Commands zu erzeugen. Diese Commands werden über die Edit Domain ausgeführt und damit funktioniert Undo und Redo.
Ah den Extension Point hab ich noch gar nie beachtet, gut dann macht das Sinn =)
 
G

Gast2

Nein, das stimmt nicht, siehe hier (ich habe im Ecore ein zusätliches Attribut 'name' eingefügt:
Java:
public class ViewPart1 extends ViewPart {

	private TreeViewer viewer;


	@Override
	public void createPartControl(final Composite parent) {
		viewer = new TreeViewer(parent);
		AdapterFactory factory = new ProvidermodelItemProviderAdapterFactory();
		viewer.setLabelProvider(new AdapterFactoryLabelProvider(factory));
		viewer.setContentProvider(new AdapterFactoryContentProvider(factory));
		final Node root = ProvidermodelFactory.eINSTANCE.createNode();
		Node child = ProvidermodelFactory.eINSTANCE.createNode();
		root.getChildren().add(child);
		viewer.setInput(root);
		parent.getDisplay().timerExec(1000, new Runnable() {
		
			@Override
			public void run() {
				root.getChildren().add(ProvidermodelFactory.eINSTANCE.createNode());
				parent.getDisplay().timerExec(1000, this);
				for (Node node : root.getChildren()) {
					node.setName(SimpleDateFormat.getTimeInstance().format(new Date()));
				}
			}
		});
		
	}

	@Override
	public void setFocus() {
		viewer.getControl().setFocus();

	}

}
1.Klappt das eigentlich auch irgendwie wenn als input mehrere roots hat? oder muss man dann extra noch ein Root Object anlegen in EMF?

Also ich hab quasi eine Klasse Root und die kann mehrer Nodes aufnehmen.
Ich habe mehrere Roots die würde ich gerne auch anzeigen lassen.

2. Unterstützt die Factory auch DeferredTrees? Oder muss man hierfür noch etwas anlegen?
Also es wäre schön wenn da auch "Pending" steht wenn das Laden der Kinder etwas länger dauert? Ist das so ohne weiteres möglich?

Also sowas :
Java:
	        AdapterFactory factory = new ProvidermodelItemProviderAdapterFactory();
	        viewer.setLabelProvider(new AdapterFactoryLabelProvider(factory));
	        viewer.setContentProvider(new AdapterFactoryContentProvider(factory));
			List<Root> roots= new ArrayList<Root>();
			for(int i = 0 ;i < 5; i++){
				Root root = ProvidermodelFactory.eINSTANCE.createRoot();
				for(int j = 0; j<5;j++){
					Node node = ProvidermodelFactory.eINSTANCE.createNode();
					root.getChildren().add(node);
				}
				roots.add(root);
			}
	        
	        viewer.setInput(roots);
 
Zuletzt bearbeitet von einem Moderator:
1.Klappt das eigentlich auch irgendwie wenn als input mehrere roots hat? oder muss man dann extra noch ein Root Object anlegen in EMF?
Wenn etwas nicht funktioniert mach dir einfach einen ContentProvider der an einen AdapterFactoryContentProvider delegiert aber bestimmte Anfragen anders/selbst handelt.

2. Unterstützt die Factory auch DeferredTrees? Oder muss man hierfür noch etwas anlegen?
Also es wäre schön wenn da auch "Pending" steht wenn das Laden der Kinder etwas länger dauert? Ist das so ohne weiteres möglich?
Eclipse bietet dafür schon eine fertige Klasse. AFAIR hieß sie DeferredTreeContentManager
 
Hallo zusammen,
ich habe eine Frage bitte bezüglich EMF Forms.

Ich bin bis jetzt dazu bekommen, dass ich aus einer XSD ein Listobjekt nun nur Pull-Down-Menü in EMF Forms bekomme, und das wäre die Fragestellung, wie ich aus einer XSD eine ListBox in EMF Forms bekommen kann?
Ist das möglich? Oder es ist schon so festgelegt?

Außerdem könnte man die UI nach der Erstellung irgendwie als XML Beschreibung (Also XML Datei) abspeichern?

Ich bedanke mich im Voraus für eure Antwort und Unterstützung.

Beste Grüße
Alan Jaff
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben