Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Gyrex/Concepts/Admin UI"
< Gyrex
(New page: in progress ...) |
|||
Line 1: | Line 1: | ||
− | in | + | {{Gyrex}} |
+ | |||
+ | === Admin UI Page === | ||
+ | |||
+ | *every page has to extend FilteredAdminPage or AdminPage | ||
+ | *need a constructor which sets title (setTitle) and titletooltip (setTitleToolTip)<br> | ||
+ | *you have to override at least super methods activate() and createControl(final Composite parent) which returns a Control | ||
+ | *new Composite in parent compsite can take all other composites, shells, widgets, ... | ||
+ | *layout should be GridLayout | ||
+ | *with Infobox possibility to set paragraphs and help text | ||
+ | *for new horizontal arrangement create new composite with more columns | ||
+ | *it is possible to create further classes, where composites and widgets are arranged | ||
+ | *in createControl the classes have to be called or without further classes this is the place to arrange composites and widgets | ||
+ | *order of declaration of widgets/more composites defines order of appearence | ||
+ | *for clear code outsource code snippets for complex buildings such as the (filtered)trees or declaration of a few buttons in a row in methods | ||
+ | *almost every swt widget can be used, such as [[#Buttons|buttons]], [[#Labels|labels]], [[#Dialogs|dialogs]] | ||
+ | |||
+ | <br> | ||
+ | |||
+ | === Buttons === | ||
+ | |||
+ | *from swt package | ||
+ | *with initialization assigned to parent composite | ||
+ | *for clear code, it's better to have a method for creating a button where definition, initialization, text settings and LayoutData settings are placed | ||
+ | *the added selectionListender needs a SelectionAdapter which on widgetSelected(SelectionEvent) calls a method with code presenting the functionality | ||
+ | *depending on functionality they can be enabled or not (could be managed in separate method, too) | ||
+ | *for separation use of [[#Labels|labels ]] | ||
+ | *can open [[#Dialogs|dialogs]] | ||
+ | |||
+ | <br> | ||
+ | |||
+ | === Labels === | ||
+ | |||
+ | *from swt package | ||
+ | *with initialization assigend to parent | ||
+ | *without text good possibility for separating buttons | ||
+ | *LayoutData is GridData with horizontalAllignment SWT.BEGINNING and verticalAllignment SWT.CENTER (in case of use for separation) | ||
+ | |||
+ | <br> | ||
+ | |||
+ | === TreeViewer === | ||
+ | |||
+ | *gets data via setInput() | ||
+ | *can have SlectionChangedListener(ISelectionChangedListener), OpenListener(IOpenListener) | ||
+ | *ISelectionChangedListener has the selectionChanged(SelectionChangedEvent) method which has to be overriden | ||
+ | *IOpenListener has the open(OpenEvent) method which has to be overriden | ||
+ | *can be refreshed, that means to show new information getting from the viewer's model | ||
+ | *has a comparator for sorting elements | ||
+ | *with a LabelProvider the columns of the tree are filled with texts or labels | ||
+ | |||
+ | |||
+ | |||
+ | === Dialogs === | ||
+ | |||
+ | *should extend either Infobox, NonBlockingMessageDialogs or NonBlockingStatusDialog | ||
+ | *if they don't extend them they has to contain openNonBlocking(DialogCallback) method from NonBlockingStatusDialog or NonBlockingMessageDialog for proper lifecycle | ||
+ | *can be opened by clicking a button who has to call the dialogs openNonBlocking(DialogCallback) method; the callback has to define what to do after closing the dialog by pressing "OK" (clicking "Cancel" has no further effect) | ||
+ | *dialogs getting parent shell as parameter, should be set as a member variable in constructor where to create super instance with this parent | ||
+ | *set title and shellStyle in constructor as well | ||
+ | *override super methods createDialogArea(Composite), okPressed() | ||
+ | *createDialogArea defines the arrangement of widgets like fields,buttons, checkButtons, radioButtons, ... | ||
+ | *all widgets are from package admin.ui.internal.wizards | ||
+ | *checkButtons and radioButtons can be created as a SelectionButtonDialogFieldGroup | ||
+ | *for a single radio or check button use SelectionButtonDialogField | ||
+ | *to validate values of fields use IDialogFieldListener, which has to be set for every StringDialogField | ||
+ | *same as in createControl a new composite has to be created for the widgets | ||
+ | *in most cases buttons in dialogs are to add or remove applications, logger or something else, because of this they are implemented in ListDialogFields; in customButtonPressed() you get the button, who was clicked and can call the appropriate method | ||
+ | *ListDialogFields are from admin.ui.internal; has to have a IListAdapter (from admin.ui.internal, too) who provides the customButtonPressed() method | ||
+ | *if an object has to be edited, just append it as a parameter when you call the dialog, then in the constructor assign it to member variables, in fields the existing values can be set to edit | ||
+ | *okPressed() executes code after clicking the "OK" button at the dialog, super.okPressed() has to be called to close window | ||
+ | *super.okPressed() return Window.OK code, clicking "Cancle" returns Window.CANCEL as default |
Revision as of 12:19, 14 August 2012
Gyrex | |
Website | |
Download | |
Community | |
Mailing List • Forums • IRC • mattermost | |
Issues | |
Open • Help Wanted • Bug Day | |
Contribute | |
Browse Source • Project Set File |
Admin UI Page
- every page has to extend FilteredAdminPage or AdminPage
- need a constructor which sets title (setTitle) and titletooltip (setTitleToolTip)
- you have to override at least super methods activate() and createControl(final Composite parent) which returns a Control
- new Composite in parent compsite can take all other composites, shells, widgets, ...
- layout should be GridLayout
- with Infobox possibility to set paragraphs and help text
- for new horizontal arrangement create new composite with more columns
- it is possible to create further classes, where composites and widgets are arranged
- in createControl the classes have to be called or without further classes this is the place to arrange composites and widgets
- order of declaration of widgets/more composites defines order of appearence
- for clear code outsource code snippets for complex buildings such as the (filtered)trees or declaration of a few buttons in a row in methods
- almost every swt widget can be used, such as buttons, labels, dialogs
Buttons
- from swt package
- with initialization assigned to parent composite
- for clear code, it's better to have a method for creating a button where definition, initialization, text settings and LayoutData settings are placed
- the added selectionListender needs a SelectionAdapter which on widgetSelected(SelectionEvent) calls a method with code presenting the functionality
- depending on functionality they can be enabled or not (could be managed in separate method, too)
- for separation use of labels
- can open dialogs
Labels
- from swt package
- with initialization assigend to parent
- without text good possibility for separating buttons
- LayoutData is GridData with horizontalAllignment SWT.BEGINNING and verticalAllignment SWT.CENTER (in case of use for separation)
TreeViewer
- gets data via setInput()
- can have SlectionChangedListener(ISelectionChangedListener), OpenListener(IOpenListener)
- ISelectionChangedListener has the selectionChanged(SelectionChangedEvent) method which has to be overriden
- IOpenListener has the open(OpenEvent) method which has to be overriden
- can be refreshed, that means to show new information getting from the viewer's model
- has a comparator for sorting elements
- with a LabelProvider the columns of the tree are filled with texts or labels
Dialogs
- should extend either Infobox, NonBlockingMessageDialogs or NonBlockingStatusDialog
- if they don't extend them they has to contain openNonBlocking(DialogCallback) method from NonBlockingStatusDialog or NonBlockingMessageDialog for proper lifecycle
- can be opened by clicking a button who has to call the dialogs openNonBlocking(DialogCallback) method; the callback has to define what to do after closing the dialog by pressing "OK" (clicking "Cancel" has no further effect)
- dialogs getting parent shell as parameter, should be set as a member variable in constructor where to create super instance with this parent
- set title and shellStyle in constructor as well
- override super methods createDialogArea(Composite), okPressed()
- createDialogArea defines the arrangement of widgets like fields,buttons, checkButtons, radioButtons, ...
- all widgets are from package admin.ui.internal.wizards
- checkButtons and radioButtons can be created as a SelectionButtonDialogFieldGroup
- for a single radio or check button use SelectionButtonDialogField
- to validate values of fields use IDialogFieldListener, which has to be set for every StringDialogField
- same as in createControl a new composite has to be created for the widgets
- in most cases buttons in dialogs are to add or remove applications, logger or something else, because of this they are implemented in ListDialogFields; in customButtonPressed() you get the button, who was clicked and can call the appropriate method
- ListDialogFields are from admin.ui.internal; has to have a IListAdapter (from admin.ui.internal, too) who provides the customButtonPressed() method
- if an object has to be edited, just append it as a parameter when you call the dialog, then in the constructor assign it to member variables, in fields the existing values can be set to edit
- okPressed() executes code after clicking the "OK" button at the dialog, super.okPressed() has to be called to close window
- super.okPressed() return Window.OK code, clicking "Cancle" returns Window.CANCEL as default