I need a web UI with pages like "Info", "Support", etc. That's easy.
In addition, I have some "plugins" with their own "editors", which need to be shown in the same web UI.
It's something similar to "Extensions" page shown in Google Chrome: every extension has an "Options" link, which can contain any editor the extension wants.
So, my main application does not know upfront how many "plugins" and editors it has. All it knows is how to call the plugin's "showEditor()" method.
(this is how it's currently implemented in my Eclipse-based desktop app, which I'm trying to port to web)
I'm wondering if GWT is applicable for this kind of applications. So far looks that GWT applications are "monolithic" and all pages / panels need to be referenced in the common "gwt.xml" file, which means I can't configure the distributive to include only "core plus plugin1 and plugin2" or only "core plus plugin 2 and plugin 3" - I have to always include everything since it's referenced in the common xml file.
there's no requirement to install/update additional plugins AFTER the application is built and installed - this should make the task easier.
Any ideas how to use "modularity" with GWT so that UI panels can come from several "modules/plugins"?
Related
I am new to eclipse scout. My question is how do i customise the default application look and feel for an eclipse scout application. I want to be able to change the button colors and replace the default icons with my own. I was able to change some of the colors using the application.css file but i did not archieve much. Also, is there a way of getting the ids, or class names for the various components in the resulting web pages so that i can be more granular in styling them.
Thanks in advance.
How you can style an Eclipse Scout application depends on which front-end you use: RAP, Swing or SWT.
Swing
You can use the Scout Swing Spy to determine the class name of a component in your UI when you have it selected.
If you use the Rayo look and feel, you can use implement the interface ILookAndFeelConfigurator and register it for the extension point org.eclipse.scout.rt.ui.swing.lafconfigurator to change the theming by providing a custom XML. The Rayo concept wiki article explains this in more details.
If you do not use the Rayo LaF...
RAP
The default RAP theme is modelled after the Rayo theme mentioned above.
Changing it involves creating your own theme bundle and create the appropriate CSS file there. Given that it is a RAP theme, you'll have to refer to the RAP RWT Theming guide. See the Scout forum thread "Scout Web App + CSS".
For reference, this is the Rayo CSS file of the Eclipse Scout 5.0 in the eclipse scout git repository (org.eclipse.scout.rt.ui.rap.theme.rayo)
SWT
Given that the SWT UI is designed to be portable and uses the widgets provided by the operating system, the amount of customization is more limited.
You can use the extension point org.eclipse.scout.rt.ui.swt.lookAndFeel to adjust some values of the look and feel (see schema file). See also the Scout thread "Modifying SWT look and feel for disabled elements"
you can make your own button and you own icon by use photoshop first bro
then copy the file into res/drawable of your application project
I already have a standalone Eclipse RCP application. The next task is to integrate the plugins which are widely used in the Eclipse community like CDT or say PyDev to provide the editing and debugging facilities in respective programming languages inside the already developed RCP app. Just wondering how do i go about accomplishing this task. Should i start with playing around the extension points of the plugins and adding it to the MANIFEST.MF ?
What are the various ways of achieving this ? Which one to pick over the other?
The most important thing you should consider (besides the technical) is a conceptional.
Plugins like CDT are making a lot of assumptations about their environment they are integrated into. That means your RCP should have a very similar user-interface and behavior like the normal Eclipse SDK so that the integration of other "IDE-ish" plugins is not a break of the interface principles of your RCP.
If your RCP is not based on a common navigator, projects, files (in general the Workspace) and several editors the integration of Plugins like CDT will be a nightmare for your users and will feel like another application within your RCP.
Make also sure that ui-contributions from third-party-plugins are visible (e.g. if the third-party-plugin is contributing a preference page, make sure that your RCP has the menu-item to open the preference-window)
First you have to load the new features/plugins in your existing RCP application. For this you have to adapt your product definition and load the new feature.xml files. or you enhance your own feature.xml and place the new plugins into.
Afterwards you have to decide, whether the new functions/view/perspectives are contributions to an already existing RCP extension point and whether you use this extension point in your RCP product.
If you want to use the new functions in another way (because the default is not enough) you have to point to specific views/actions in the new plugins and call them by your self. Fot his you have to adapt the MANIFEST.MF of your own plugin and point to the new plugins. If you do it, you can not switch off the added features, because you do have a jard link to these plugins.
Your RCP product already depends on the RCP feature (org.eclipse.rcp) or a subset of its plug-ins. This means, it already includes the plug-ins defining the basic extension points.
To include functionality (extensions) from additional features, just add these features to your product configuration dependencies. For example, you would have to add the feature org.eclipse.cdt for CDT and org.python.pydev.feature for PyDev.
The hard part begins when you need to include only some of the features' plug-ins.
You'll have to isolate the plug-in(s) providing the functionality you require.
For UI contributions, you can use the plug-in selection spy by selecting the required UI part and clicking alt+shift+F1.
For non-UI contributions, information for contributed extensions can be found in the plugin.xml files in the plug-in sources.
These plug-ins, along with their dependencies can be added to a custom feature, which can be included in your product.
Although dated, the article Building a CDT-based editor might also be of help.
I am on searching special features of GWT which are present only in GWT and not in other web framework. I am a student and I am not well acquainted to the many web frameworks on the market, so if u can help me increasing my list of special GWT features, it would be a great help. Some which i know are:
1. GWT allows using java to program
web. (only, it also allows merging
javascript through JSNI of course)
2. The developer does not have to be a guru in browser incompatibilities
to develop web sites which works on
a variety of browsers because
incompatibilities are handled by GWT
through differed bindind
3. GWT allows easy integration of popular Java Tools such as ,
hibernate through gilead
4. GWT enables server implementation not only in java but also other
languages such as php
5. GWT enables code splitting which improves application interactivity
by allowing javaScript file to
download only when required
6. In essence GWT is toolkit, it does not force a way to program,
other layers can be placed on top of
it to program such as placing MVP or
MVC framework on top of GWT and then
develop app
7. GWT MVP is great because first it allows collaborative working, faster
testing with JUnit and the event bus
allows many updates in client side
application by placing event on the
event bus
8. GWT compiled java files to obfuscated mode which is first small
and make the application safer
because bots fails on the javascript
generated during the obfuscated mode
In case in the 8 points, i've mention something which not special to GWT, then let me know.
There's also 'perfect caching', which is the term used to describe the way that GWT optimises JavaScript for each browser.
Instead of building a large JavaScript file, with code that can handle all of the various browsers, GWT builds multiple JavaScript files at compile time, and downloads only the one that is relevant to the browser type that is being used.
EDIT: Every time you make a change to your Java code, GWT changes the name of the corresponding JavaScript file. Web servers can turn on caching for the JavaScript files (so that browsers won't re-download the same file), assured that the name will change when the Java code changes, and the browser will then download the latest version.
EDIT: I also really like the CssResource feature. By creating obfuscated CSS style names, GWT effectively gives each widget its own namespace for CSS styles; for example, I could define a 'pretty' style name on two different widgets, and have those styles using different CSS rules. Of course, it is possible to share CSS styles between widgets too.
Image resources are cool too. They optimise the way that images are downloaded and accessed.
Don't forget internationalization.
I think you pulled together a pretty decent list of differentiators there already. I think that one point worth adding is the RequestFactory feature in the most recent release, which, if you will, is simplistically speaking and RPC for data and makes it quite easy to develop Create, Read, Update and Delete - type (CRUD) of applications.
There are other, more important/wider accepted GUI-Frameworks that are based on Java.
There are for example Struts and JSF. That's why some of your points don't fit only for GWT, but for all GUI java frameworks in general, e.g. bullet point 1, 2 & 3.
But to add another one:
I think GWT is an easy way to code an AJAX-application, because it hides the AJAX stuff quite well. Wouldn't you agree?
Furthermore, GWT is a proprietary framework (which is somehow a unique property). JSF is standardized and Struts is lead by Apache.
I'm developing an Eclipse RCP based application, that uses the resource model of eclipse (workspace, projects, resources, etc.). For basic usage of the resource concept, there is no need to depend on the IDE plug-in. But many dialogs, wizards or views I want to use are inside this plug-in. I read about not to have any dependencies on IDE plug-ins in an RCP app.
For example, I want to implement a new project wizard and use the common look and functionality of the existing ones by overriding org.eclipse.ui.dialogs.WizardNewProjectCreationPage and using org.eclipse.ui.wizards.newresource.BasicNewProjectResourceWizard - both inside the IDE plug-in.
Are there any caveats using org.eclipse.ui.ide plug-in in an RCP app?
If so, what is your best practice to not reinvent the wheel?
As you can see with this thread (or that one), since eclipse3.3, most the the components of org.eclipse.ui.ide have been isolated in their own plugin.
So it can be a good practice to include what you need from that package, the only problem being to include to much contributions.
This thread gives a hint as how to remove some of them.
You can, for example, disable export and import wizards.
Both of those examples are based on Activity filtering
An activity is a logical grouping of function that is centered around a certain kind of task.
For example, developing Java software is an activity commonly performed by users of the platform, and the JDT defines many UI contributions (views, editors, perspectives, preferences, etc.) that are only useful when performing this activity.
Activities can be used to implement progressive disclosure of UI elements; when used for this purpose, they are called capabilities in the UI.
The second use for activities, added for Eclipse 3.4, is to filter available UI elements based on other criteria such as the current user's access permissions as defined by the application.
This article "Eclipse Activities – Hide / Display certain UI elements" by Lars Vogel in his "papercut series" gives a good illustration of hiding / displaying certain UI elements.
I want to use the "Web Tools Editor" that is part of the Web Tools Plattform in my own RCP-Application. I think i have got some understanding on the RCP plattform by now, but I still have no clue how to access the functionality of the pagedesigner (org.eclipse.jst.pagedesigner) after adding it as a dependency to my project. Has anyone some experience in adding components of the web tools plattform into an RCP-Application and can give me a hint or something?
There's a difficulty with these sorts of requests (I am, myself, trying to include this or that feature that I saw in the Eclipse IDE, every so often).
The trick is to try and identify the component you want to bring in, and then try and pull it into your project, without bringing in too many dependencies.
The first step used to be quite hard, but since 3.4 it is a matter of using the Plug-In Spy - hold down Alt-Shift-F1 on whilst your desired component is in focus should give you a tooltip showing you the class, the bundle, etc etc.
The second step is altogether more tricky and is where I usuaully fail to get any results:
if you are lucky then you can just include the bundle in the launch configuration/.product of your app. Once you hit Add Required Bundles, you are not left with 3000 bundles (i.e. your RCP is now Eclipse).
usually, this is not the case, because the Eclipse team haven't refactored the bit of code you're interested in out into an RCP safe bundle. If so, then you're going to have to do that yourself.
Again, if you are lucky then that will mean moving some classes out of the eclipse bundle into your own, including internal classes, and that will be the end of it - i.e. the dependencies of your desired functionality are all within the bundle.
If you're unlucky, then you need to isolate/reimplement the bit of functionality that is required, and change your version of the copied code.
It is hard laborious, and pretty difficult to upgrade. I realise that none of this is what you want to hear.