Root-Element in TreeViewer anzeigen?

Status
Nicht offen für weitere Antworten.

dzim

Top Contributor
Hi,

bereits seit einiger Zeit habe ich einen TreeViewer in Verwendung, der für das bisherige Problem immer gut geklappt hat - hier mal ein sehr stark vereinfachtes Beispiel:
Java:
public class Root {
	public List<Child> children;
}

public class Child {
	public Object parent;
	public List<Child> children;
}

Gehen wir mal davon aus, dass beim Hinzufügen immer das parent-Attribut gesetzt wird, wir also immer den Elternknoten kennen.

Mein TreeContentProvider arbeitet nun wie folgt:
Java:
public class TreeContentProvider implements ITreeContentProvider {

	@override
	public Object[] getChildren(Object parentElement) {
		if (parentElement instanceof Root) {
			return ((root) parentElement).children.toArray();
		} else if (parentElement instanceof Child) {
			return ((Child) parentElement).children.toArray();
		}
	}

	@Override
	public Object getParent(Object element) {
		if (element instanceof Filter) {
			return ((Child) element).parent;
		}
		return null;
	}

	@Override
	public boolean hasChildren(Object element) {
		if (element instanceof Root) {
			return !((Root) element).children.isEmpty();
		} else if (element instanceof Child) {
			return !((Child) element).children.isEmpty();
		}
	}

	@Override
	public Object[] getElements(Object inputElement) {
		return getChildren(inputElement);
	}
}

(Ich weiß, der Programmierstil ist vielleicht nicht der Beste im Beispiel, soll aber nur das Problem aufzeigen)

In diesem Beispiel werden nur die Child-Elemente angezeigt, wenn ich als Input ein Root übergebe.
Ich möchte das Root-Element aber auch sehen und hab es bisher nicht hinbekommen.
Gibt es - ausser noch ein weiteres künstliches ÜberRoot-Element anzulegen - noch einen Trick den Root anzuzeigen???

Vielen Dank schon mal!
Daniel
 
Zuletzt bearbeitet:

dzim

Top Contributor
Ich hab gerade hier noch aus der JavaDoc zur Methode getElements(Object) das hier gelesen:

NOTE: For instances where the viewer is displaying a tree containing a single 'root' element it is still necessary that the 'input' does not return itself from this method. This leads to recursion issues (see bug 9262).

Sieht also wohl so aus, als würde ich wirklich nicht um ein gefaktes Root-Element herum kommen (schon doof, da ich in meinem konkreten Problem schon das Root-Element einer JAXB Klasse einer XML-Wurzel verwende).
 

Wildcard

Top Contributor
Java:
setInput(Collections.singletonList(yourObject))
Jaxb ist übrigens Schnee von gestern, EMF ist der Trend. :)
 

dzim

Top Contributor
Hey Thanks!

Ich hab es schon, entgegen dem, was ich leiden kann, wieder mit nem FakeRoot probiert, aber DIESE Version werde ich definitiv auch gleich mal probieren!

BTW: Weißt du, bei nem Kollegen und mir ist es fast schon ein Running-Gag, aber immer wenn z.B. ich schreibe, das wir das und das nehmen, kommst du mit einem passenden Eclipse-Framework daher! ;-) Nimms mir nicht übel, aber das ist echt witzig! (Zumal du wahrscheinlich zu meinem Leidwesen auch noch recht haben wirst! *g*)

[edit]
Ich hab mir mal Lars Vogels Tutorial angeschaut ( Eclipse Modeling Framework (EMF) - Tutorial ). Was mir dabei aber noch nicht klar geworden ist, wie man aus einem bestehenden XSD ein EMF-Model erstellt. Vielleicht finden wir ja tatsächlich mal etwas Ruhe um das austesten zu können.
[/edit]
 
Zuletzt bearbeitet:

Wildcard

Top Contributor
[edit]
Ich hab mir mal Lars Vogels Tutorial angeschaut ( Eclipse Modeling Framework (EMF) - Tutorial ). Was mir dabei aber noch nicht klar geworden ist, wie man aus einem bestehenden XSD ein EMF-Model erstellt. Vielleicht finden wir ja tatsächlich mal etwas Ruhe um das austesten zu können.
[/edit]
Es gibt viele Wege ein ecore zu erstellen:
-Mit dem built-in EMF Editor
-Mit annotierten Java Interfaces
-Aus UML Modellen (auch andersrum funktioniert)
-Aus XSDs
-Abgeleitet aus einer Grammatik (XText)
-Anhand einer textuellen Beschreibung (EMFatic)
-Programmatisch mit reflexivem Ecore
-...

Für den XSD Weg einfach XML Schema Infoset von der Galileo Site installieren, dann bekommst du das als option im Wizard angeboten das Genmodel aus einem XSD zu generieren.
Das nette ist, du kannst es danach beliebig im EMF Editor anreichern, mit zusätzlichen Methoden, angepasster Vererbungshierarchie, OCL constraints,... und es wird immer noch ein valides XML erzeugt.
EMF verwendet JMerge, was dir erlaubt den generierten Code nach belieben zu verändern. Beim neugenerieren bleiben deine Änderungen dann erhalten.
Ich könnte wirklich Stunden über die Features von EMF schwärmen, es gibt so viele davon :)

Übrigens, EMF macht nicht nur bei XML Bindings Sinn. Auch alle anderen Arten der Persistenz lassen sich damit verwirklichen, aber das wichtigste:
EMF macht sogar Sinn wenn es überhaupt keine Persistenz gibt, denn mit EMF werden Modelle erzeugt und jede Software braucht Modelle.
Mehr und mehr Entwickler sehen das Licht dank EMF und dem EMF Papst Ed :)
Eclipse on my mind: Lessons learned about modeling
 
Zuletzt bearbeitet:

dzim

Top Contributor
lol - das ist doch mal ein post zum Wochenende - man wird ja fast von der guten Laune angesteckt ;-)

Danke für die Tipps jedenfalls!
Speziell das hier
EMF verwendet JMerge, was dir erlaubt den generierten Code nach belieben zu verändern. Beim neugenerieren bleiben deine Änderungen dann erhalten.
ist natürlich ein Pluspunkt, denn wenn mich etwas nervt, ist es, wenn ich nach Änderungen im XSD be größeren Sachen JAXB-Klassen neu generieren lasse und ich Änderungen von Hand wieder eintragen muss (z.B. transient-teile, die nichts im xml zu suchen haben, mir aber meine arbeit in Java im Modell erleichtern)

Ok, ok, ich werd es mir definitiv mal ansehen! Da wir gerade eines unserer Schemas von Grund auf neu schreiben, wär das wohl ein recht passender Zeitpunkt, da mal dran zu bleiben.

Danke jedenfalls für deine Schwärmerei ;-)
 
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen


Oben