I want to creating a graphical editor which a physician can use to create user interfaces to define state-based interactive dialogue based diagnosis systems for simple diseases. Each screen consists of simple UI elements like a textarea,button and these are in a container to make up the state. Once he defines many screens with text and buttons or photos/videos, he wants to save the configuration in a XML file. How can I use the Eclipse modeling technologies to create a graphical editor to do this task
Example below:
I think the GMF tutorial is a good place to start: http://wiki.eclipse.org/GMF_Tutorial
Related
We use elements with composite diagrams in our models. Usually if such a composite diagram exists, then the element shows a link icon to indicate a double click will open/show the diagram.
But with ArchiMate elements the link icon is not shown unless using the rectangle notation. Is there some workarround or configuration to allways show the icon?
This screenshot illustrates the problem:
Out of the box, there is nothing you can do. There is no setting or configuration that will show the composite diagram indicator on the Archimate elements.
The reason is that the shapescript used for these elements simply doesn't include this indicator.
There are a few options to get this done anyway
1 Send a feature request to Sparx
You can use this link: https://www.sparxsystems.com/support/forms/feature_request.html to send an official feature request to Sparx Systems. They might one day implement this, but there are no guarantees at all.
2 Override the standard the ArchiMate MDG
Steps include
Create your own stereotypes in a profile, redefining the existing ArchiMate stereotypes. See the manual for more details
Include your profile into an MDG
Add your MDG to your model or environment
Set your MDG to Active to actually make the redefines happen.
This might be interesting if you want to add additional properties (tagged values) to the standard ArchiMate stereotypes as well. I'm not so sure if it's worth the trouble just to add the composite indicator.
3 Hack the existing Archimate MDG file
The Archimate MDG is defined in the file C:\Program Files (x86)\Sparx Systems\EA\MDGTechnologies\ArchiMate3.xml. This is an XML file that you can open with any text editor. The shapescripts are included in binary form like this
<Image type="EAShapeScript 1.0" xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="bin.base64">
UEsDBBQAAAAIAGaEbU+CvMH4PQIAADAKAAAHABEAc3RyLmRhdFVUDQAH1zDMXdcwzF3XMMxd
zVVJTsNAEOyrkfhDFC6OlAP7IsSRF/AAlMSJY5FNjgMKiL9T1Z3B9tiJAxKLLI9nqamumV68
lLH0ZCFDackUvURmcigH8qZtIBPMrWUuK8nwrBV5J23pYy6VCKMUo9sNeobZpTJG6L0AmWF9
BZRDWJvISELFLcGYAkveVC2E4EsxGmDUA2MMDUNl5jjD3jlGbeniPcbbwWOsTnOgukbgTuQV
vVDO5AL4K+A7n0oCrJORVhfKPAayuD6E5Qk4FkCS5RT7u/pea3vm8VFltIVrBB6y8USRWuap
n7CnHj/F6jNWM3xDqK+zR20zD+OfsYw5UQzbMqrO2m6mm72YzB75mpjKmPfNlx7g3Tf51zh8
xdUoChWXK687AWOXHlohxi2WGZuMSnqKa1QfbyKQkbjf7hn6U/Rt30AYLZlY/hQZ3Dff3fIs
O0R+H4FmEe+EfOxF2D0EPsY3Qx4ydnMb7n7rrTmldXbG8ohVejAGjpWgfJLcRqA1YgIl1Srg
FPM8md7O0afVI+8+nFb7Wsu3qJh51RdGC1ec3u32GVOMPiqIVQU1LFGx6B2LEafBdvx0xdrv
Nvw7YB4M9By5nRb6VMLZ4m3Yac1XOZoeZC7mnvuN8zbl91crMyuj+Y01oCvnXk7vqszfq8W+
hf9fi+3vtbsW23+trhY3xRxnprg//v8TYTUgtjn2HuS+EHt/G3VN1hPMV89pFl2FKdotV04/
Zl0UufbS80x1BxEO7f5f1V1lr1tm+F73/W5Z46PqKu8HUEsBAhcLFAAAAAgAZoRtT4K8wfg9
AgAAMAoAAAcACQAAAAAAAAAAAACAAAAAAHN0ci5kYXRVVAUAB9cwzF1QSwUGAAAAAAEAAQA+
AAAAcwIAAAAA
</Image>
If you replace that section with a shapescript of your own, it will happily accept that. You can create this format by creating your own profile in EA and then exporting the package as a UML profile. EA will then convert your shapescript into this binary format.
I one published the shapescript for most of the MDG's, including ArchiMate3 on github. That might give you a head start when developing your own.
or "How to decouple UI from business logic in Delphi?"
Each target platform has its own set of native firemonkey controls (Windows=VCL, MacOS=TMS mCL, Android=D.P.F, iOS=TMS iCL and D.P.F). The new FireUI (multi-device form designer) is a great solution for styled components, but not for native components because it still requires the same component on the master pane to support all platforms. As you cannot mix them on the same form, it completely breaks the whole idea with Delphi.
A lot of developers would say that Delphi is the broken approach, see "Why FireMonkey is so fundamentally wrong in every aspect". However, the premise for this question is NOT to argue against Delphi, but to get the best results out of what it does offer.
The conclusion is then that for each form in your application you have to make a separate form for each target platform. This leads to these questions:
Challenge 1: How to include different form files in your project depending on your target platform?
Solution 1: include all of them, i.e. MainForm_IOS.pas, MainForm_Android.pas, MainForm_Win, MainForm_OSX.pas, and then use compiler directives inside the files, so only the content of one of the files is active. Disadvantage: a large application can have many forms (we have around 40), so we are talking about a large number of included files.
Solution 2: Do not include them in the project, but instead just place them in seperate folders. Then you can add the matching folder to the search path for each target platform. Disadvantage: They will not show up in the Project Manager, so it will slow down the workflow every time you need to find a file.
Solution 3: Create a project for each target platform. Disadvantage: Every time you add new units or change common project settings you have to (remember to) apply it to all projects.
Update: As suggested in the Malcom Groves video, placing all the business logic in a package will remove the disadvantage from Solution 3. So I consider solution 3 as the best approach.
Challenge 2: How to connect the different device forms to the (same) business logic?
Possible solution: Create a "Helper" class that contains all the code you would normally have in the form unit.
Update: This "Helper class" is actually what the MVVM calls a ViewModel. What I need seem to be a MVVM framework that can support the databinding. I have made another question about that.
Any input and suggestions about best practice are welcome.
For challenge 1:
You can conditionally link in your FireMonkey form resources depending on the compile target:
{$R *.Windows.fmx MSWINDOWS}
{$R *.Macintosh.fmx _MACOS}
etc.
This is excatly what the XE7 Multiview designer does, but I see nothing against using this mechanism to link whole form files conditionally in to your executable. Of course you might also want to ifdef the corresponding units in your project file.
For challenge 2: Just use some form of Model View Controler logic. So your platform dependant forms will talk to a platform independant controler.
Currently I have some validation in the main project which the UI project interprets as markers. I would like move that validation from the main project to the UI project, so that the parser is not concerned about it. Also I would like to add validations and marker messaging which need some data from preferences, so these have to be in the UI project as well, aimed to enrich the UI experience. What is the best way to plug in several model validations (preferably separate) which would get the marker-displaying support of Xtext?
Don't do that. The validation is part of your model. If you move it to the UI plugin, other EMF tools can access your model without being bound to the validation and could create invalid models (because they do not trigger your validations).
Preference pages are shown in UI plugins, but preference values are stored in so called preference stores, which are accessible from non UI plugins. Therefore using preferences to tune validations is no reason to move them to the UI plugin.
I'm investigating Adobe CQ5 and would like any advice on how to integrate its drag-and-drop UI to create a responsive website. It seems as if it works on a concept of fairly bland templates with components that can be dropped in pretty much anywhere, including things like "three-column control" - which would make designing a responsive grid structure very hard (as it would be hard to prevent users from dropping in a control that could ruin the layout).
Does anyone have any experience or advice on this? I'm really looking for deep technical details on the structure of templates vs components (paragraphs), and where/how to manage to the CSS.
CQ5 offers ways to control what can be done within a template, so thinking that components "can be dropped in pretty much anywhere" may be misleading. Page templates are designed and configured so that you control which components can be added to a certain area of a page. This allows you to only make those components available that will work with the template layout, excluding components that would wreck the layout. Then authors are only allowed to use things that will work. If they attempt to drag a component onto a paragraph (parsys) where that component has not been configured as available, the UI will not allow them to use it there. So CQ actually makes it easy to prevent users from dropping a control somewhere that would ruin the layout.
This is outlined a bit here:
http://dev.day.com/docs/en/cq/current/howto/components_develop.html#Adding%20a%20new%20component%20to%20the%20paragraph%20system%20%28design%20%20%20%20%20mode%29 which states that
"The components can be activated (or deactivated) to determine which
are offered to the author when editing a page."
When it comes to CSS and JavaScript, you can create a client library and then include the relevant client library on the page. Backend CQ functionality will take care of combining multiple CSS (or JavaScript) files into a single minified file to allow for a single HTTP request of an optimized file. This it outlined a bit here:
http://dev.day.com/docs/en/cq/current/developing/widgets.html#Including%20the%20Client-Sided%20Code%20in%20a%20Page as well as
http://dev.day.com/docs/en/cq/current/howto/taglib.html#%3Ccq:includeClientLib%3E
So you might develop several components that share a client library, then when any of the components is added to a paragraph the client library will be included on the page. You may also want a CSS library that applies to all the templates to give a common look and feel, yet allow components to add their own when they are used.
These guidelines for using templates and components outline how you provide control, yet flexibility:
http://dev.day.com/docs/en/cq/5-5/developing/developing_guidelines_bestpractices.html#Guidelines%20for%20Using%20Templates%20and%20Components
I'll document our successful WIP experience with RWD and CQ5
Assumptions:
A well documented style guide.
Our First Steps:
Modified existing column control component css to utilize twitter bootstrap grid css.
Create a base page property allowing two different classes on the grid container to be set and inherited by child pages. (container||container-fluid).
Leverage out-of-the-box components where ever possible.
All component widths inherit the width of their parent container allowing for components to be dropped into any location within a template.
Issues:
The out-of-the-box column control component can not be nested.
We are looking into building a custom column control component.
Takeaways: this is an evolutionary project and we are constantly iterating.
With the recent launch of AEM 6.0, they have an example website called as Geomatrixx Media. This website is responsive.
You can take this example as reference and start building on top of it.
I have a Wizard with two pages: pageone extending WizardNewProjectCreationPage, and pagetwo is extending WizardPage. I want the user to be able to create the project first, and then add files to the project on the second page.
For the latter I want to use a SWT Table (?) like when you pick an interface in the Java Class Wizard in Eclipse IDE (cf. picture here). Also the "Add" button next to it.
How can I achieve this? Do I have to use Eclipse Forms API for this? Or simply add a SWT Table? I have used the Plug-In Spy but the source code given in NewClassWizardPage and NewTypeWizardPage seems to be very specific to this example and I cannot make sense of it.
I've also had a look at vogella's tutorial for JFace table, but I can't get my head around it.
Just some basic steps would be great, or maybe somebody has done this before?
I can easily understand why you're confused... there are indeed many ways to do this. You even left out Data Binding which provides you with yet another way to populate and decorate the table in question.
To sum up the usage of the different APIs:
SWT provides the basic widgets and controls. Often these have a rather irregular low-level interface - especially compared with Swing - but you need to access the SWT controls to lay them out (an exercise that can be complicated in itself). Also many of the listeners are on the controls.
JFace provides a set of viewers on top of the corresponding structured SWT controls - e.g. TableViewer on top of Table. These viewers provides a high-level interface to the functionality of the underlying control - e.g. with models, label providers, sorting, filtering and more. (The viewers can easily be compared with the Swing counterparts...)
Eclipse Forms provides a (relatively) simple way to create views, dialogs, etc that looks like web pages. Examples of this are the various PDE editors.
Data Binding provides a (somewhat complicated) way to bind controls (including Tables) to a data structure (Bean, EMF or POJO based).
So... you have to decide on whether to use the model facet of JFace and Data Binding, but the rest of the APIs are often combined in the same view or dialog.
NewClassWizardPage and NewTypeWizardPage are both particular complicated examples of wizards - don't base your own work on these!
For your particular case - as I understand it - I would use a simple JFace TableViewer to hold the list of interfaces... (I use a TableViewer rather than a ListViewer as the later cannot have an image as part of the label provider.) The "Add" and "Remove" buttons will manipulate the model of the viewer and then update the viewer. You don't need Eclipse Forms as the wizards usually don't look like web pages. And Data Binding is also an overkill here given the very, very simple data for the wizard.
Please note that the function of a wizard is only performed after all the wizard pages has been shown and the "Finish" button is pressed.