# Agreeing on optional user interface hints in templates

**URL:** <https://discourse.openehr.org/t/agreeing-on-optional-user-interface-hints-in-templates/2406>\
**Category:** Specifications\
**Tags:** ux, forms\
**Created:** [3 March 2022 08:03 UTC](https://discourse.openehr.org/t/agreeing-on-optional-user-interface-hints-in-templates/2406 "2022-03-03T08:03:49Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 March 2022 13:29 UTC](https://discourse.openehr.org/t/agreeing-on-optional-user-interface-hints-in-templates/2406/23 "2022-03-09T13:29:36Z")

</div>

> [@pieterbos](#):
>
> However, if data binding is made separate from the language, and you cannot use a path anywhere else in the language, this will complicate these issues very much - then you cannot easily express ‘I want these rules to apply to this event in this observation only, even if the event occurs multiple times, but I still want to reference other data in the observation outside of the single event’.

Wouldn’t you just create a more specific binding for that particular event, to a more specific variable, e.g. ‘Apgar\_heartrate\_5\_mins’ or similar, when you might already have ‘Apgar\_heartrate’? Or you are talking about apply these rules in the sub-tree at this path? For the latter I think you would define a binding to the container object (HISTORY or whatever) under which you want a `for_all` or `there_exists` to execute.

It’s an interesting question generally as to whether the binding needs to be separate from the language. I have made the assumption that it does because the bindings in GDL, Task Planning and Archetypes are all completely different.

> [@pieterbos](#):
>
> if data binding is separate, but sub-paths are still possible, and a for\_all block is added, then the problem is also easily solved.

I am more inclined to this approach - because with only symbolic vars in the EL, EL texts are least is readable and maintainable. This goes back to our [discussion last year](https://discourse.openehr.org/t/rules-in-archetypes-a-migration-path/1252).

---

_[View the full topic](https://discourse.openehr.org/t/agreeing-on-optional-user-interface-hints-in-templates/2406)._