Fw: [uiml] FW: Implementation specifics for UIML behavior rules

> Hello everyone,
>
> We currently have a Bachelor's thesis student working on improving the
> implementation of behavior rules (conditions and actions) in our
> renderer.
>
> He ran into a few difficulties however. There are some difficult cases,
> such as multiple events in the condition statement, or only a property
> in the condition statement. Here are a few examples:

[snip]

Sorry Robbie, after going through it again, I overlooked a few things. Here are my comments ...

> 2) suppose we want to fire an action when a certain checkbox is
> 'checked' (property checked == true)
>
> The problem here is that we need to check the state of the user
> interface. However, the checked property is reflected in the underlying
> final user interface. In our renderer, the value of this property will
> only be made consistent with the concrete widget's value when we
> explicitly demand the value of this property (e.g. <property
> part-name='checkbox' name='checked'/>).
>
> One solution is to constantly poll to update the state of the user
> interface, but is clear that this is not an elegant solution. Especially
> on mobile devices this would pose problems as it would consume too much
> energy (and would drain the battery).
>
> Although one might think there is an event for checking or unchecking a
> checkbox, we can't do this for every property. Suppose we want to fire
> an action when a widget's color is red. There is no event for changing
> the color of a widget.
>
> James, how have you at Harmonia implemented this? Robbie, I suppose you
> solved this through with variables?

A simple solution is to go without events in such a case:
In fact, you also know the color of a widget, as you change the property
value.

Well this is not completely true I guess, since some properties have default values ( e.g. the color of a widget). Of course you could get all possible properties defined in the vocabulary on startup, but that would again be resource intensive ...

I can also believe a property could be changed without setting the property explicitly in UIML. Suppose the underlying widget set alters a certain property?

Now
in DISL we can specify rules without events and just check if a set of
properties and
variables contain the right value. This is what I called the "eventless"
transition in
one of our previous discussions. The current specification allows an
<op>-Element as
a child of a condition, so the following should be possible.

    <condition>
      <op name="equal">
        <property name="color" part-name="someWidget"/>
        <constant value="red"/>
      </op>
    </condition>

Indeed, that was also how we thought about it ...

For implementation, we defined interaction cycles which trigger the
behaviour resolver, so if
some state change occurs, we start a new phase of evaluating all the
conditions. That's why we don't have to check for specific events per se in
the rules.

Maybe this could be a way to go for you?

That might be an option, but again you need to know when something changes ...

I don't think the spec should be changed here, but maybe we could add an
explanation, how
eventless transitions could be implemented, at least if all agree with this
approach.

uiml message