Composition or Association for Deep Entities a

Hi all,

I was hoping for some advice and direction on the best way to proceed with CUBA given a complex model but fairly simple browse / edit UI.

I have a model that might be a few levels deep and at the lower levels there are many entities say 20-30

This isn’t my model but I’m just trying to give a simple example so go with it…

School has many Grades
Grade has many Classes
Class has many Students
Student has many (addresses, results, parents etc)

In this situation School would be considered a top level Edit Entity. The other entities I guess fall in to what would be considered Compositions (at least they would in the real model) as they don’t really exist in their own right without the parent entity all the way up to School.

What I want to do is create a simple UI for this but I would like to not have to run in to issues with too much data being loaded at the root Top Level Edit screen in the main datasource. I would also like to have some sort of tab sheet with lazy loaded tabs at the Student level to show the child entities in the usual tables.

I don’t know how best to structure the model relationships as either Compositions which they are or Associations for other reasons such as performance?

I’m also unsure if the best approach is to create nested datasources or create all the data as linked datasources in their own right?

Can anyone give me advice on if this type of model will work ok and how best to structure my relationships?

Many thanks


generally I have a github example called springfield-school-management which deals with the described business domain.

I added some nested levels to add your problem to the example. In this case I did: “Grade” <>–> “Course” <>–> “Exam” <>–> “ExamResult”.

You can take a look at it to familiarize yourself with the structure of the UI and the entities.

All of these entities are in a composition relationship. So the grade would be your “top level edit entity”.

Well in fact only because they are in a composition relationship, that does not necessary mean that they get all loaded into the first editor. This depends on how you do the view definition of your top level entity.

The question is, if you really want to in a single “UI transaction” go down all these levels. Oftentimes this is not very user friendly, because people get lost being into this tree of very similar looking screens.

Instead you should try to cut at two levels (at the latest). In fact CUBA really natively supports two levels of nesting for storing the information in a single “ui transaction”.

Here’s a good example in the docs, that describes the problems with more levels of nesting and offers solution for this problem:

They offer two approaches. The one that I described is more like the second approach, where they split the screens.

When you always cut after two levels, you can easily go to 10 or 20 levels deep.

Are you more concerned about how the UI would look like, or is it only about performance?

For me the basic question has always been how to actually structure the UI properly to not totally loose the users on their way.

To help you further, you have to be a little more concrete about what you want to know or what are your concrete questions / problems.


Hi @mario

I’ve actually been looking through your site recently. There is some good information in there.

Thanks very much for modifying your example to show me a bit more of what I was doing. I think my main concern is that the initial loading of data for views has way too much in it and that composition wasn’t going to allow lazy loading. I think some of the documentation could go in to a little more detail about what happens in the background with loading data for forms and how the entity linking is handled for example with saving as single transactions.

I know the getting lost in a UI can be easy and I’m trying to work out how to handle the depth.

What I don’t want in my UI if for the user to get too deep without saving some data. Again I get confused here because from what I read a composition link means data is in memory until the top item is save then it is all sent in one transaction. I don’t really want loads of data entered without save points.

I had a look at some of your other repositories and some of those are quite interesting and what I was looking at having in the system . The following were of particular interest.


I may have questions on those if that is ok?

Could I email you directly?

Thanks again

I’m not 100% sure about it, but i think not being able to do lazy loading has more to do with how you setup your view and if you use nested datasources in comparison to linked datasources or not. It is not directly related to composition vs. association.

What works quite good, is that you don’t treat the higher levels at your entry point of the UI. E.g. when you want to edit the “Exam Results” you start with the browse screen of the “course” and not on the browse screen of the “grade” in order to let the UI path don’t get to long.
In CUBA it is very easy to create these browse screens that start at an intermediate level. You can also scope (via a UI filter) them so that they are just like an edit screen of a particular “course” with a subtable of the corresponding “exams”.

Exactly. This is one big problem with too nested structures as well. The user normally doesn’t really get when the save actually will be applied. Especially when at some level (for technical reasons) this does not work anymore to save everything only when the uppermost level is saved. This is why splitting the UI tree is also important.