Migration from Classic to Flow UI

Hi

I’m trying to define current (2.0) jmix coverage of features and addons that were in cuba 7.2. With the ultimate goal of planning migration of my projects to jmix when it’s ready.

In JMix 1.5 doc there is a table component
https://docs.jmix.io/jmix/1.5/ui/vcl/components/table.html

In last JMix documentation there is none
https://docs.jmix.io/jmix/flow-ui/vc/components.html
image

I thought there was maybe some hints there, no luck
https://docs.jmix.io/jmix/migration-from-classic-ui.html
image

So I’m a bit confused. Maybe your plan is to keep only datagrid ? Did not found any info on that, but that could make sense, classic components are so close.

Is there some synthetic document somewhere that lists features and addons that are not yet implemented in jmix ?

Regards
Michael

Hi Michael,

The Migration from Classic UI :: Jmix Documentation section is now available.

The replacement for Classic UI Table and DataGrid in Flow UI is dataGrid.

Regarding missing parts that will definitely be implemented, see our roadmap. The plan for October 2023 release includes Flow UI for some add-ons, as well as ViewSettings facet and aggregation in DataGrid.

Regards,
Konstantin

1 Like

Thanks for the feedback @krivopustov.

That’s exciting, it means that the coverage of 2.1 release will allow me to begin the migration process to jmix for my projects.

I’m particularly eager to see that:

It will be very interesting to see how you implement the combination of grouping and lazy loading. From my doorstep it opens a path for the development of powerful components to manipulate figures.

Regards,
Michael

Perhaps you confuse aggregation and grouping. By aggregation I mean this feature of the classic UI dataGrid/table.

We will work on an alternative to classic UI GroupTable too, but later, see Grouping DataGrid.

Ok, I made the assumption that both features would be implemented at once, like classic GroupTable.

Sadly, that will be an issue for my apps where GroupTable is rather widely used. I will have to seek or develop an alternative or wait for the GroupingDataGrid to come.

Even if the component has its limits, GroupTable is quite handy to present figures, like turnover reports and the like, if you want something lighter than a BI solution e.g Pentaho. It’s also handy to display hierarchical information, and by extension intermediates aggregations, like in the screenshot below.

image

The only thing with GroupTable is that you have to be very careful with the paging when manipulating figures. Need to ensure that groups displaying intermediates aggregations have their chunk of data not cut by the page limit.

This particular point is why I’m curious to see how you will implement grouping in DataGrid.

It’s probably too early to ask you more hints on the matter.

Michael

2 Likes

Hi Michael

Thanks for the feedback. We know that GroupTable is widely used and we’re certainly willing to reimplement it in Flow UI.

BTW there is an idea that could help with paging in GroupTable: Sort by grouping fields when using GroupTable · Issue #1242 · jmix-framework/jmix. What do you think?

1 Like

Interesting idea, but probably a partial answer to the problem. E.g if the page limit is 50, and one group is aggregating records from 47 to 53, a sum for instance, the sum will be calculated on records 47 to 50. And if a group aggregates more than 50 records, same issue.

I don’t see a simple and definitive solution for this issue with GroupTable, it’s simply a limit of the component to take into account.

It can be circumvented for instance by tuning the page limit on the fly (custom code), or by tuning the number of records loaded in a custom CollectionLoader to a number 1) that allows only complete groups while 2) keeping this number under the page limit, or close to it. For instance, in the previous example, the first page loaded could be 46 or 53 records long.

What is interesting with lazy loading is that theoretically paging is not needed anymore. From the user POV you just scroll through a dataset. Of course there can be some paging internally for performance reason. It can be implemented in different ways.

Let’s see when it’s there :slight_smile:

Michael

1 Like

Sure, it can make more correct only grouping, not aggregating.

Interesting idea. Theoretically it’s possible, but needs intermediate requests to count group sizes.