Eclipse Community Forums: Eclipse SmartHome » Thoughts on a new Sitemap Concept

Help

Home

Home » Archived » Eclipse SmartHome » Thoughts on a new Sitemap Concept

Show: Today's Messages :: Show Polls :: Message Navigator

Thoughts on a new Sitemap Concept [message #1715906]

Fri, 27 November 2015 14:34

Dennis Nobel

Messages: 166
Registered: September 2014

Senior Member

Hi,

I want to share some thoughts on a new sitemap concept based on some discussion I had with several people.

The current sitemap concept has a few problems:

* It´s main representation is an Xtext DSL, which brings a heavy dependency. The current idea in ESH is to remove all dependencies to the DSLs in the core and to the DSL as one optional way how to configure the system. This was already done for the Items and the Things.
* It is not editable via REST (mainly because of the previous point)
* It´s not really component-oriented (meaning definitions can be reused)

So I want to start with requirements for a new Sitemap concept:

1) should be represented as a plain Java model
2) editable via REST with a proper JSON model
3) should be modular and should allow to reuse components and define composition (like the rule engine)
4) it is easy to extend with specific features
5) it should allow to define how the UI represents the smart home, but should not invent a fully new UI framework like HTML
6) Different UIs can add specific properties to the Sitemap to allow specific arragnment or styles, that are not part of the core Item concept

Some terms for the new conepts:

1) Atom - An atom is the smallest component of a sitemap. Atoms are simple UI components like labels, buttons, sliders etc. (comparable to the Widget in the current Sitemap)
2) Container - A container groups and arranges multiple atoms and/or other containers (comparable to the Group or Frame in the current Sitemap)
3) Sitemap - The full definition of a system view Containing containers and Atoms

Atom:

The atom represents a UI component. The new sitemap concept comes with several so called "system" atoms that each default renderer MUST support. An atom defines a type ID, configurable properties and data points and/or action points. Data points and actions points is the binding between the sitemap and the the core Item model. The UI don´t have to know the Item model, it just works the data whereas the conversion is done on the server side. This is why there are two models: The Sitemap definition model and the Sitemap rendering model.

Example of an atom usage/definition:

{
    id: "TemperatureLabel"
    type: "system:Label"
    properties: {
        editable: true
    },
    data: {
        text: "@Item:MyTemperatureItem"
    }
}

Example of the resulting rendering model:

{
    id: "TemperatureLabel"
    type: "system:Label"
    properties: {
        editable: true
    },
    data: {
        text: "20 °C"
    }
}

The UI renderer does not need to know which item is bound, it just works with the data endpoint. It subscribes for events like "smarthome/sitemaps/mySitemap/TemperatureLabel/text" to receive text updates and sends a PUT to "rest/sitemaps/mySitemap/TemperatureLabel/text" if the label ws changed in the UI. The Java logic maps the Item and performs the according commands.

Example of the "Toggle Button atom":

Example of an atom usage/definition:

{
    id: "MyToggle"
    type: "system:ToggleButton"
    data: {
        state: "@Item:MySwitch"
    }
}

Example of the resulting rendering model:

{
    id: "TemperatureLabel"
    type: "system:Label"
    properties: {
        editable: true
    },
    data: {
        state: true
    }
}

List of possible system atoms:

Atoms:
* Label
* Input
* Button
* ToggleButton
* Select
* MultiButton
* Slider
* Colorpicker
* Image

There might be of course more atoms. Every solution can also define new atoms in another namespace and use them in sitemaps. But default renderer will not be able to render them. It might be worth to think about Atom inheritance to allow fallback rendering in case a custom atom is used and the renderer does not know it.

Container:

Containers can arrange Atoms. Therefore there might be different containers for different layouts like a LinearContainer or a GridContainer. Another possibility is to just define one Container with layout arguments. Containers itself should be reused in order to allow composition.

Even a binding might define containers for it´s things, so that the UI can use them in order to come up with a good default interface for a thing.

Notes on DSL and compatibility:

It should still be possible to define a sitemap with an easy DSL syntax, as the JSON might be hard to specify. Maybe the existing DSLs can be used and transformed into the new sitemap concept.

These are just some thoughts and there is definitely a lot of discussion left.

Regards

Dennis

Breadcrumbs

Sign up to our Newsletter