Hi all, in this blog Im going to share my insights on ui5 xml composite controls feature I recently tried out.
My use case: complex ui that displays the same backend state in real time from different perspectives.
In this particular case we have a game where some players fight against boss or other players.
So, each actor has states and depending on that – corresponding actions (or even significantly different ui presentation )
Plus the backend sends us events through websockets, so all the stuff happens really fast.
So, the basic idea here is to have a list aggregation to bind all of the backend states to, so that the template is cloned to render the state of each actor and available controls.
And of course we can use a good old xml fragment for that:
With something like this to deal with visibility and state of the buttons:
But after watching the Evolved Web Apps with SAPUI5 open sap course I decided to take a look at new (at least for me) composite xml control feature (refer to w3u5 video of the course)
And thats how it would look in the same fragment:
Of course, under the hood of the composite there is still a fragment definition, so you can easily migrate your existing fragments to it.
The code below is not a direct migration of previous fragment
But why would you do that?
In general I would describe all the benefints of using it in one word: encapsulation.
What that meant for me was I could:
- Rename properties names to make it clearer
- Hide complex property bindings definitions with lots of paths
- Move formatters logic out of controller // that I really liked
- Proxy events with custom event parameters or do some intermediate stuff
- Have own style and i18n separated from the parent component
- Plus all models can be used as in regular fragment to bind to them // which can allow you do some dirty and hacky stuff
A good example of this model+events+internal logic magic would be the “spell casting” mode: as we have a two way binding to the outside model, we can change the property castMode inside the control (in performAction handler), this way all the other controls (which all are bound to it) will update itself and display the spells (3rd picture).
After any spell button is pressed, the performCast handler is called and the actual event performAction event is fired and the castMode is set back to false.
And the controller just knows that some player’s action needs to be handled:
Not sure my use case is a good example, as I even guess it can be a real framework features abuse, to be honest, but I strongly recommend giving it a try in case you missed this stuff.
Thanks for reading.