XWT - UI Trigger (1)
One of the most common features of any modern application, whether web-based or client-based, is the dynamic aspect of user interface elements. These include buttons that highlight when focused or clicked, images that change when the mouse is rolled over them, text boxes that change color to indicate errors, the visibility/edit-ability of input fields through operator profile or/and data behind.
In almost of cases, this kind of interactivity is achieved through the use of some kind of scripting mechanism or in Java through event handling. In web pages, for example, there is usually some JavaScript code that is assigned to execute when certain events are triggered on a given page element, like an <IMG> tag whose src attribute changes in response to mouse-over and mouse-out events.
In XWT, you can achieve the same kinds of interactive effects without writing a single line of script or Java code by using a feature known as Triggers. These triggers are defined within styles or a specific UI element to respond to changes on a given property and event of the object. When they are triggered, some actions defined in XML will be executed. One of the most useful action is the Setter, which set the values of other properties on the object. In general, a trigger is somewhat like an if block in procedural code; it only executes what it contains when some condition evaluates to true.
There are five kinds of triggers, each has a different way of determining when it should execute:
- UI Property trigger
- Multiple UI Property triggers
- Data Property trigger
- Multiple Data Property trigger
- UI Event trigger
Along with Control Binding, Trigger is another powerful feature to minimize the pure UI codes in Java and keep Java code more readable.
UI Element Property trigger
The source of a property trigger is UI Element. The condition is defined by two attributes: property and value. Each Trigger has a list of Setter.
The properties changed by triggers are automatically reset to their previous value when the triggered condition is no longer satisfied. Triggers are optimized for transient states which are expected to change and return to original state, such as selection of a check button.
The property Trigger construction is very simple. It consists of a <Trigger> tag, which usually encloses one or more <Setter> tags. The <Trigger> tag also has attributes that govern its actions. The Property attribute indicates the property of the triggered object that the trigger is listening for changes on. The Value attribute contains the value that will cause the Trigger to fire when it is equal to the value of the property that is being watched. It usually looks something like this:
<Trigger Property="selection" Value="true"> <Set Property="text" Value="green"/> </Trigger>
This trigger can be defined in the property triggers of a Style, which will be applied to all buttons:
<Style targetType="Button">
<Style.triggers>
<Trigger property="Selection" value="true">
<Setter property="text" value="Selected"/>
</Trigger>
</Style.triggers>
</Style>
or directly in a UI Element
<Button x:Style="CHECK" text="Unselected">
<Button.triggers>
<Trigger property="Selection" value="true">
<Setter property="Text" value="Selected"/>
</Trigger>
</Button.triggers>
</Button>
This code indicates when the CheckBox Button gets selected, the text value will be changed to "Selected". When you deselect this button, the previous value will be restored.
If you want to apply the action to another UI element, you just need to add an attribute targetName with the name of referenced UI element as value:
<Button Name="Button1" x:Style="CHECK" text="Unselected"/>
<Button x:Style="CHECK" text="Button State">
<Button.triggers>
<Trigger property="selection" value="true">
<Setter property="Text" value="selected" targetName="Button1"/>
</Trigger>
</Button.triggers>
</Button>
You’re not limited to just one Setter in a Trigger. You can have as many Setter as you like. And for a style or a UI Element, you can have as many Trigger as you like.
<Button Name="Button1" x:Style="CHECK" text="Unselected"/>
<Button x:Style="CHECK" text="Button State">
<Button.triggers>
<Trigger property="selection" value="true">
<Setter property="Text" value="selected" targetName="Button1"/>
<Setter property="selection" value="true" targetName="Button1"/>
</Trigger>
</Button.triggers>
</Button>
Multiple UI Element Property trigger
I can imagine many of you saying "well, that’s pretty nice feature, but what if I want some actions only when two different or more triggers match their Value conditions at the same time?". For example, you might want to call Setter to a control only when that control both has the input focus and has the mouse over it.
The MultiTrigger is defined for this purpose. Each MultiTrigger has a list of Condition. Each condition is composed of at least two attributes: property and value. An optional attribute "sourceName" can be used to indicate the source of condition.
<Composite>
<Button Name="button1" x:Style="CHECK" text="Condition 1"/>
<Button Name="button2" x:Style="CHECK" text="Condition 2"/>
<Label Name="messageLabel"/>
<Composite.triggers>
<MultiTrigger>
<MultiTrigger.conditions>
<Condition property="selection" value="True" sourceName="button1" />
<Condition property="selection" value="True" sourceName="button2" />
</MultiTrigger.conditions>
<Setter property="text" value="OK" targetName="messageLabel" />
</MultiTrigger>
</Composite.triggers>
</Composite>
In this example, we define a MultiTrigger in a Composite which contains two CheckBox buttons. When and only when both buttons get selected, a message "OK" will be displayed in Label.
Next post will address on Data Trigger and Multiple Data Trigger. The Event trigger is used to UI animation, which will be covered later. Keep tune!
Posted October 12th, 2009 by Yves YANG in category: XWT
You can skip to the end and leave a response. Pinging is currently not allowed.
9 Responses to “XWT - UI Trigger (1)”
Leave a Reply
You must be logged in using your Eclipse Bugzilla account to post a comment.
ekkehard Says:
October 12th, 2009 at 5:51 pm
nice idea, but….
… how do you localize it ?
in business apps values are never hardcoded
Yves YANG Says:
October 12th, 2009 at 5:59 pm
you can use the binding expression with static extension
text=”{x:Static y:Message.Name}”
where y the prefix of a namespace corresponding to Java package, Message is a Java Resource bundle, and name is a static constant.
It is already supported by XWT
Erdal Says:
October 14th, 2009 at 1:05 pm
Can this also be applied to viewers?
See http://www.eclipse.org/forums/index.php?t=msg&th=155894&start=0&S=5c8d14ffa36fae8250bc04b4ff719861
How can this be used to make a viewer reload its input based on the selection of another control?
Yves YANG Says:
October 14th, 2009 at 6:52 pm
Sure. I have answered you in the forum.
Stephan Says:
October 15th, 2009 at 3:53 pm
I personally think, most of this is a step backwards!
As far as I understood, the idea was to separate UI notation and behavior.
But now you give again e.g. with setter the possibility to add behavior where it NOT should be, in the UI declaration.
What is the next step?
Loops, Calculation, … At the end why we need java any more?
We have a new language and we are at the starting point, putting all in one …
-> stop it now !
PS: I know this is provoking but what do other think? everybody viewless?
Yves YANG Says:
October 15th, 2009 at 4:20 pm
>As far as I understood, the idea was to separate UI notation and behavior.
>But now you give again e.g. with setter the possibility to add behavior where it NOT should be, in the UI declaration.
It is the separation of UI aspect with business logic behind. All presentation aspect should stay as maximum as possible in declarative UI.
>What is the next step?
>Loops, Calculation, … At the end why we need java any more?
Java is used to develop application model, business logic and other aspects that Declarative XML doesn’t handle.
JD Says:
October 16th, 2009 at 3:11 pm
Nice.
While I second Stephan’s opinion, I recon it can be used quite well to provide additional feedback to the user, though.
Nevertheless Stephan is right. It is dangerous from an architect’s point of view. There will be a lot of programmers out there who will be tempted to implement enforcement of constraints, which can not be put directly into the model on this level. For example something among the lines “Checkbox A must be checked when Checkbox B is checked. Quite like you’ve actually showed in the examples, Yeves.
What’s really needed here is a declarative controller-markup in the middle, which binds the model to the GUI.
Yves YANG Says:
October 16th, 2009 at 5:42 pm
For sure, the data binding is important and fundamental. XWT already supports it, which is demonstrated in the e4 contact demo:
http://wiki.eclipse.org/E4/XWT/Running_the_demos
And this concept is also showed in e4 Webinar. You just need to select the Java model class, and then you generate the presentation with data binding.
The declarative UI about dynamic aspect is nice-to-have, particularly for MDA: UI generation based on business model. Can you image the difficulties to generate dynamic control in Java code?
ekkehard Says:
October 17th, 2009 at 4:43 am
I’m going a different way - we’re developing redview http://redview.org
(Riena EMF Dynamic Views for Business Applications)
all SWT Widgets (more from Nebula will come) are available,
can be designed from a WYSIWYG editor inside eclipse IDE
with live-pushing to running RCP Apps thru CDO
all based on EMF models and dynamically rendered at Runtime
– first releases in nov/dec
runs on eclipse 3.6 - at beginning of 2010 we’ll also integrate with e4
redView is developed with the goal to simplify RCP Business Applications and based on Eclipse Runtime (Riena, Equinox) and Eclipse Modeling (EMF, CDO) with integration to Xpand/Xtend/MWE for a whole model-driven life-cycle
ekke