Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Sapphire » Graphiti Integration
Graphiti Integration [message #663960] Wed, 06 April 2011 19:04 Go to next message
Brian Fitzpatrick is currently offline Brian Fitzpatrick
Messages: 495
Registered: July 2009
Senior Member
Hi guys...

Has anything been written up about the Graphiti integration with Sapphire? I just started playing with it a bit and have run into some entertaining limitations.

For example, I can only define graphical nodes for properties of the root element of my model. If I try creating one for a child property (the next level down), it complains that the property doesn't exist in the root element. Is there a way to nest these perhaps?

Really that's what I'm after - showing some kind of containment hierarchy in a box within a box approach. Something similar to the node/node-list hierarchy for the Form Editor Page definition.

Obviously it's very early in the process for the Graphiti integration pieces. But there's been some movement lately in the Architecture and Map editor samples, so I'm hopeful there will be more to play with soon.

I still think Sapphire could very well be the holy grail of editor frameworks uniting many technologies in a consistent way. Gotta love it.

Keep up the great work guys!
--Fitz
Re: Graphiti Integration [message #663974 is a reply to message #663960] Wed, 06 April 2011 22:51 Go to previous messageGo to next message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 940
Registered: July 2009
Senior Member
The diagram support is still a very new feature. No docs yet. Just samples and the sdef editor to go on.

You will find that the scope of feature development at Sapphire is bound by immediate needs of adopters. We implement just enough of the feature to meet those needs and refactor when needs expand. So if you find a case where the framework doesn't support what you are looking to accomplish, open an enhancement request describing your usecase and we will go from there.

> Really that's what I'm after - showing some kind of containment
> hierarchy in a box within a box approach.

We currently do not support this usecase. Just top-level diagrams. Please open an enhancement request.

> For example, I can only define graphical nodes for properties of the
> root element of my model. If I try creating one for a child property
> (the next level down), it complains that the property doesn't exist in
> the root element. Is there a way to nest these perhaps?

Is this related to the diagram in a box scenario or is there a case where this comes up with top-level diagrams?

- Konstantin
Re: Graphiti Integration [message #664403 is a reply to message #663960] Fri, 08 April 2011 12:25 Go to previous messageGo to next message
Brian Fitzpatrick is currently offline Brian Fitzpatrick
Messages: 495
Registered: July 2009
Senior Member
Ok, I've created bug 242312 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=342312) for my enhancement request with a couple of screen shots illustrating what I'm looking/hoping for.

As for the other issue, it's not really related to the enhancement request as much as just trying to figure out how to define lower-level nodes.

Each node has a Property associated. In the Switchyard case that I'm working on, it now has two Properties - composites and transforms. And I'm able to define two Nodes for the diagram element in the sdef just fine.

The problem comes when I try to define a node for one of the elements the next level down. For instance, the "composites" property defines a bunch of "composite" elements. Each "composite" element has "services" and "components" and so on and so forth...

When I try to define a "Property" property for a new node that's a deeper level, it throws a hissy fit because it can't find it in the top-level Switchyard element. This makes sense, but I'm not quite sure how to define a nested Property that points to deeper elements...

Is it possible to provide a path to deeper elements? Such as: composites/services?

When I try this (or any other combination of paths) I get an exception:

!ENTRY org.eclipse.ui 4 0 2011-04-08 10:23:29.226
!MESSAGE Unable to create editor ID org.jboss.tools.switchyard.editor.graphical: Could not find property composites/services in org.jboss.tools.sapphire.ISwitchyard
!STACK 0
java.lang.RuntimeException: Could not find property composites/services in org.jboss.tools.sapphire.ISwitchyard
	at org.eclipse.sapphire.ui.SapphirePart.resolve(SapphirePart.java:460)
	at org.eclipse.sapphire.ui.SapphirePart.resolve(SapphirePart.java:444)
	at org.eclipse.sapphire.ui.diagram.editor.DiagramNodeTemplate.init(DiagramNodeTemplate.java:97)
	at org.eclipse.sapphire.ui.SapphirePart.init(SapphirePart.java:148)
	at org.eclipse.sapphire.ui.diagram.editor.SapphireDiagramEditorPart.init(SapphireDiagramEditorPart.java:71)
	at org.eclipse.sapphire.ui.SapphirePart.init(SapphirePart.java:148)
	at org.eclipse.sapphire.ui.swt.graphiti.editor.SapphireDiagramEditor.<init>(SapphireDiagramEditor.java:95)
	at org.jboss.tools.sapphire.ui.SwitchyardGraphicalEditor.createDiagramPages(SwitchyardGraphicalEditor.java:73)
	at org.eclipse.sapphire.ui.SapphireEditor.addPages(SapphireEditor.java:317)
	at org.eclipse.ui.forms.editor.FormEditor.createPages(FormEditor.java:138)
	at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:348)
	at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:670)
	at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:465)
	at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
	at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:313)
	at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:180)
	at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:270)
	at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
	at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:473)
	at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1245)
	at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1198)
	at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1597)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:493)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103)
	at org.eclipse.ui.internal.PartStack.add(PartStack.java:479)
	at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112)
	at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63)
	at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:225)
	at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:213)
	at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:778)
	at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:677)
	at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:638)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2942)
	at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2850)
	at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPage.java:2842)
	at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2793)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2789)
	at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2773)
	at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:331)
	at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:179)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4150)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3739)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
	at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1386)


--Fitz
Re: Graphiti Integration [message #664405 is a reply to message #663960] Fri, 08 April 2011 12:26 Go to previous messageGo to next message
Brian Fitzpatrick is currently offline Brian Fitzpatrick
Messages: 495
Registered: July 2009
Senior Member
Here's my sdef for the diagram page:

    <diagram-page>
        <id>diagram</id>
        <page-name>SwitchyardDiagram</page-name>
        <page-header-text>SwitchYard Diagram</page-header-text>
        <node>
            <id>composites</id>
            <tool-palette-label>composite</tool-palette-label>
            <tool-palette-desc>service composite</tool-palette-desc>
            <property>composites</property>
            <label>${Name == null ? &quot;&lt;composite&gt;&quot; : Name}</label>
            <instance-id>${Name}</instance-id>
        </node>
        <node>
            <id>transforms</id>
            <tool-palette-label>transform</tool-palette-label>
            <tool-palette-desc>service transformation</tool-palette-desc>
            <property>Transforms</property>
            <label>&lt;transforms&gt;</label>
            <instance-id>transforms</instance-id>
        </node>
        <node>
            <id>services</id>
            <tool-palette-label>service</tool-palette-label>
            <tool-palette-desc>service</tool-palette-desc>
            <property>composites/services</property>
            <label>${Name == null ? &quot;&lt;service&gt;&quot; : Name}</label>
            <instance-id>${Name}</instance-id>
        </node>
    </diagram-page>
Re: Graphiti Integration [message #664431 is a reply to message #664405] Fri, 08 April 2011 15:54 Go to previous messageGo to next message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 940
Registered: July 2009
Senior Member
> Is it possible to provide a path to deeper elements? Such as:
> composites/services?

It is conceivable that we could support that, but we first need to understand what the semantics of this would be.

I can see allowing intermediate element properties as that doesn't introduce big semantic questions. The intermediate element is either there or its not. If the chain of elements isn't created, we can create it on node addition.

Intermediate list properties are more of a problem. Listing nodes could be just a matter of collecting all elements from all sub-trees, but what about addition? There is not enough in the specification to know which sub-tree to add the new element to. My guess is that list inside list case more naturally maps to the diagram in a box scenario.

- Konstantin

[Updated on: Fri, 08 April 2011 15:55]

Report message to a moderator

Re: Graphiti Integration [message #664434 is a reply to message #664431] Fri, 08 April 2011 16:05 Go to previous messageGo to next message
Brian Fitzpatrick is currently offline Brian Fitzpatrick
Messages: 495
Registered: July 2009
Senior Member
Yeah, I guess this really is the box in a box scenario more than anything else. If you have the context of a box representing a level of the tree you could add or change the palette to represent what's valid to add/remove at that particular level...

Bummer. But I look forward to seeing if it's even a supportable case. Smile

--Fitz
Re: Graphiti Integration [message #664437 is a reply to message #664434] Fri, 08 April 2011 17:06 Go to previous messageGo to next message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 940
Registered: July 2009
Senior Member
> Bummer. But I look forward to seeing if it's even a supportable case.

At this point, I would say that we are unlikely to support list/list case outside of the diagram in the box scenario. The element/list case we could support. Do you have a need for this? If yes, please open an enhancement request.

- Konstantin
Re: Graphiti Integration [message #664439 is a reply to message #664437] Fri, 08 April 2011 17:13 Go to previous messageGo to next message
Brian Fitzpatrick is currently offline Brian Fitzpatrick
Messages: 495
Registered: July 2009
Senior Member
I'm not sure that it would be useful to have element/list support in the diagram without the added context of the box/box approach. For now I'll leave my other enhancement request open and leave this alone.

Is it possible to access the underlying Switchyard model via a public API? I'm just wondering if it would be worth creating a custom editor page and hacking something in to connect it to Graphiti?

--Fitz
Re: Graphiti Integration [message #664440 is a reply to message #664439] Fri, 08 April 2011 17:23 Go to previous messageGo to next message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 940
Registered: July 2009
Senior Member
> Is it possible to access the underlying Switchyard model via a public
> API? I'm just wondering if it would be worth creating a custom editor
> page and hacking something in to connect it to Graphiti?

Sure. Take a look at SapphireEditor class and getModelElement() method. You can weave Sapphire pages with non-Sapphire pages in the same editor. Of course, building a graphical editor from scratch isn't exactly trivial, even with Graphiti...

It would help us to know if you have moved beyond proof of concept stage on this. If we knew that you are planning on adopting Sapphire in a given product release, we could conceivable give higher priority to some of the bigger enhancement requests from you (like the diagram in a node).

- Konstantin
Re: Graphiti Integration [message #664445 is a reply to message #664440] Fri, 08 April 2011 17:59 Go to previous messageGo to next message
Brian Fitzpatrick is currently offline Brian Fitzpatrick
Messages: 495
Registered: July 2009
Senior Member
Konstantin Komissarchik wrote on Fri, 08 April 2011 17:23
Sure. Take a look at SapphireEditor class and getModelElement() method. You can weave Sapphire pages with non-Sapphire pages in the same editor. Of course, building a graphical editor from scratch isn't exactly trivial, even with Graphiti...


Yeah, understood. And thanks.

Konstantin Komissarchik wrote on Fri, 08 April 2011 17:23
It would help us to know if you have moved beyond proof of concept stage on this. If we knew that you are planning on adopting Sapphire in a given product release, we could conceivable give higher priority to some of the bigger enhancement requests from you (like the diagram in a node).


Well, I would certainly say I'm impressed with the framework. It's extremely useful as it is right now. So yes, I think I can say with little doubt (have to discuss it some with Max, my boss, and our releng folks) that I'd like to include this Switchyard editor with our release due out in early 2011 based on the Indigo release.

It wouldn't be a supported product yet, but it would be an experimental editor for a platform that's quickly gaining some speed. And probably available in JBoss Tools or as a separate download.

I'll have to chat with a few folks to see if that's possible or not, but it should be doable.

My concerns are the same as many devs - it's a young framework with potential to change drastically along the way. When do you see it maturing to a 1.0 release? Obviously post-Indigo I'm guessing. If you continue to add functionality and yet keep it fairly stable, it would be an easier sell. So far that's been the case, but since I'm consuming nightly builds pretty regularly I'm taking the risks. Smile

Are there any other devs/companies (beyond me at RH/JBoss and you guys at Oracle) looking at adopting Sapphire? You mentioned you were already building and supporting some Oracle tools on it when we chatted at EclipseCon...

--Fitz
Re: Graphiti Integration [message #664453 is a reply to message #664445] Fri, 08 April 2011 19:28 Go to previous messageGo to next message
Brian Fitzpatrick is currently offline Brian Fitzpatrick
Messages: 495
Registered: July 2009
Senior Member
I mean 2012, not 2011... We're already there unless I use the Einstein Express to go backwards...
--Fitz
Re: Graphiti Integration [message #664457 is a reply to message #664445] Fri, 08 April 2011 21:21 Go to previous message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 940
Registered: July 2009
Senior Member
> I'll have to chat with a few folks to see if that's possible or not, but it
> should be doable.

Ok. Please keep us in the loop as your plans evolve.

> My concerns are the same as many devs - it's a young framework
> with potential to change drastically along the way.

Well, not young, just young at Eclipse. Sapphire has been in development and shipping in various BEA/Oracle product releases for roughly five years now.

> When do you see it maturing to a 1.0 release? Obviously
> post-Indigo I'm guessing.

Yes, definitely post-Indigo. The 0.3 release will ship concurrently with Indigo, but will not be in the common repository (we are not part of the release train). The 1.0 question comes down to project graduation criteria. One criteria that I have placed is a major non-Oracle adopter. You may very well bring that.

> If you continue to add functionality and yet keep it fairly stable,
> it would be an easier sell. So far that's been the case, but since
> I'm consuming nightly builds pretty regularly I'm taking the risks.

You can expect every Sapphire release to be stable. Obviously there is more risk of running into a bug if you track integration builds, but the need to do that should diminish over time.

In terms of API, you can expect Sapphire to behave very differently in this regard than other Eclipse projects. In particular, I do not wish to fall into the trap of never shipping an API breaking release. The framework needs to be able to evolve before and after the 1.0 release. To make this easier on adopters, we plan to do the following:

1. All runtime components will be non-singleton (in OSGi sense). That means that plugins of two adopters on different versions of Sapphire can co-exist in the same install. We aren't quite there yet, but are making progress. This is a 1.0 criteria.

2. We will continue to produce service releases on all past major releases as long as needed by adopters who haven't migrated to the latest release.

3. Every API-breaking release will come with a detailed migration guide. We have already started the practice of putting these together. You can see the 0.2 and the in-progress 0.3 one in the Sapphire Developer Guide in help.

> Are there any other devs/companies (beyond me at RH/JBoss
> and you guys at Oracle) looking at adopting Sapphire?

Not that I know of. There have been questions on this forum, but I haven't seen evidence of anyone else moving beyond questions.

> You mentioned you were already building and supporting some
> Oracle tools on it when we chatted at EclipseCon...

Oracle Enterprise Pack for Eclipse (the JBoss IDE analog) has at least six good size editors built using Sapphire along with a menagerie of dialogs, wizards and views. We have basically stopped hand-coding GUIs in the last couple of years. The last OEPE release shipped on Sapphire 0.2.1 and the next feature release will ship on 0.3.x. For that release, we are working on two more editors. These will take advantage of diagram support.

- Konstantin

[Updated on: Fri, 08 April 2011 21:23]

Report message to a moderator

Previous Topic:BooleanValue/IntegerValue
Next Topic:Element ordering in XML based on DTD
Goto Forum:
  


Current Time: Thu Aug 21 06:24:02 EDT 2014

Powered by FUDForum. Page generated in 0.02804 seconds