Jmix 1.3 released

Announcements
#19

Well, I see 2 options:

  1. Define TextArea second to last (in case of 2 columns)

Screenshot 2022-07-21 at 17.07.52

  1. Use 2 FormLayouts inside main FormLayout, e.g.:
<formLayout id="mainForm">
    <formLayout id="leftForm">
        <!-- Use one column by default -->
        <responsiveSteps>
            <responsiveStep minWidth="0" columns="1"/>
        </responsiveSteps>

        <textField label="Text Field"/>
        <textArea label="Text Area" height="8.4em"/>
    </formLayout>

    <formLayout id="rightForm">
        <!-- Use one column by default -->
        <responsiveSteps>
            <responsiveStep minWidth="0" columns="1"/>
        </responsiveSteps>

        <textField label="Text Field"/>
        <textField label="Text Field"/>
        <textField label="Text Field"/>
    </formLayout>
</formLayout>

Screenshot 2022-07-21 at 17.07.57

For now, only views allowed in the menu.xml, in the future we’ll plan to support different menu item types.

1 Like
#20

I liked your option 2 using FormLayout inside a formLayout. An in future, you may consider creating from the designer and an option to drag-n-drop the components between FormLayouts…

#21

Any comments Gleb?

#22

If I correctly got the thread flow

then, currently we have neither a project template that contains both UI and Flow UI modules nor Studio functionality to add a Flow UI module to an existing Jmix project, only a template for a new project based on Flow UI.

Gleb

#23

Gleb,
Got it about the UI which is very clear (Vaadin 8 application’s end of life in CUBA/JMIX) but now I wanted to know if there is/will be any way we could migrate just the database tables and recreate the UI using Flow UI. Is it a reasonable proposal?

regards

#24

Hi @mortoza_khan ,

The non-UI layer like entities will be completely untouched when you switch the UI technology.

So the Entities, all business logic and all UI code that does not depend on Jmix UI code will work without any changes.

The actual effort for a migration to the new UI layer will be during porting over all your UI logic.

You can generate new FlowUI screens for entities, but all the controller logic you put on your old UI controllers will be lost in any case.

So if you have a big code base with a lot of UI logic, it might make sense to try to introduce own abstractions, or simply pull out as much possible logic outside your controllers into dedicated beans and avoid a lot of compile time dependencies in those beans to Jmix UI code. With that you have prepared a lot and decoupled quite a bit of UI code from the old Vaadin UI.

If you have a small code base in terms of customizations, then regenerating and replicating functionality might be the faster way to go.

In both cases having a good automated test suite in place will help you. If you went the UI integration test route, you will need a lot of adjustments to the tests (depending on how much abstractions you put into your test suite).

For selenium based E2E tests it might be less, but since the DOM elements also changed there will also be changes needed.

Cheers
Mario

#25

Hi Mario
This is what i was referring to. Since we have to create as a new project when we want to use FlowUI, how can we migrate the Entities? Copy it to the new project? I didn’t see the Entities are compatible as is.

#26

Hi Gleb
I have added the Reports ad Application Settings add-on to this application from the Market place but it is not added to the menu. Thanks for giving hints on how we can add it to the menu.

#27

I’m not sure if there will be any support from the studio plugin, probably other can tell you more about such plans.

Practically speaking you can just create a new blank project with flow UI with the same root package name, project ID etc. and then open up both projects in IDEA.

Then you can simply do a single copy and paste of the whole project tree without the UI controllers and then generate the UIs one by one and do the migration.

Alternatively you can copy your whole project, and manually add the dependencies to the flow UI. Then Studio will also recognize the new UI module and you can go ahead and generate the new screens - or simply change the dependencies in place directly.

Cheers
Mario

Jmix 1.3x and Flow UI Composite project
#28

Hi Mario
I tried to copy, but It didn’t work. Looks like the Entity definition is a bit different that needs some kind of conversion. That’s why I was asking if there will be studio support to do that. Otherwise, whole things need to be recreated. For example, I already have started to recreate a small project that I originally started in the previous version. However, I have a large project (Entity > 1000) for which some automation in the studio will greatly help.

Looking forward to the comments from the JMIX team.

#29

It is working for me. Just copied entities from old project in jmix (not cuba) and changed the abc in com.xyx.abc.

#30

Manually anything is possible. Question is, which one is optimal! My project is a very large one!!

#31

For me it worked when I tried it for the Petclinic example project quite well. Nothing needs to be changed in the entity definition. I simply copy & pasted the entities and generate new CRUD screens and this was about it (of course in a real world scenario it would also require i18n messages, liquibase migration scripts and more).

Here you can see how I did it: Jmix Flow UI Migration - Petclinic Entities - YouTube

It is also independent of how much entities you have in you application, since the copy & paste operation will be a one-time effort anyways. Simply select all of them and copy them over.

I think there is no need to have any kind of support for this particular operation from the plugin side, since copying over the entities is definitively the smallest effort of the migration.

The effort of creating a 1-to-1 replication of the UI functionality for each UI screen will probably be a 100x effort compared to copying over those classes.

So if there should be any migration support, then it would probably is this area. But I would assume that is quite a heavy lifting, as it would require to transform arbitrary UI Java code (+XML) programmatically through the plugin, which is closer to rocket science than to a CRUD generator.

At the end I think there is no magic bullet here. Vaadin 23 is a different UI framework compared to Vaadin 8. If you want to switch to this new UI technology there will be manual migration effort involved. This migration effort might be less compared to e.g. switching from Vaadin 8 to React, but it still will be a non-trivial effort when the UI makes up a big part of your application.

I personally would not count on any kind of tool to do such a transformation automagically as it is just that: a tool. Of course such effort is painful and brings less business value compared to the next business feature, but probably this is just an amount of work that you simply have to book under “infrastructure maintenance work” that every custom software development effort has in particular if it is about software that is supposed to still exists in 3, 5 or 10 years.

1 Like
#32

Thank you Mario.

#33

I’m playing around with the Flow UI in Jmix 1.3, and it makes me really excited about Jmix 1.5! :grin:

I building a proof-of-concept to migrate an application from a niche legacy technology, and I needed to wait for Jmix to make a decision on the future UI platform. Now I can start developing and expect that in a year, it will have the features I need.

I’m looking forward to:

  • tab sheet!
  • entity suggestion fields
  • data grid pagination
  • documentation on custom Flow UI components (I want to build a SurveyJS component)
  • documentation/examples for theming (not working as I expected)
2 Likes
#34

Planned for Jmix 1.5 (February 2023)

Work in progress: Implement the Pagination UI component · Issue #941 · jmix-framework/jmix · GitHub, should be included in Jmix 1.4 (October).

We strive to be as close to stock Vaadin as possible, so integration of thirdparty components and theming should be easy and as described in Vaadin docs.
Of course, integration of components into XML layout and data binding is a specific thing, but apart form that you can take any Vaadin component and use it in view controllers as is, without any wrappers, etc.

Regards,
Konstantin

#35

I can’t imagine an enterprise application without TabSheet and Reports Addon.
Vaadin helps with TabSheet: Tabs | Components | Vaadin Docs
But Reports Addon planned for middle 2023 :frowning:

1 Like
#36

I agree with you Serg.

For report, I raise a request (now in ideas group) to release it in Feb instead of Jun 2023, In response, Konstantin said “to be considered”. see here and encourage you and everyone to vote.

Hi @gorelov
With regards to TabSheet vs. Group box. I am not sure, if group box will have the same functionalities of Vaadin’s TabSheet which is currently in the pre-release version 23.3. If it is coming from vaadin soon, do you want to develop or you just make it available like other components to keep consistency?
image

#37

Hi,

Just to be clear, I have never ever suggested GroupBox as a replacement of TabSheet. I’ve mentioned that Vaadin’s Details is a replacement of GroupBox.

And yes, since Vaadin 23.3 provides TabSheet component, it will be supported in our next minor release 1.5.

Regards,
Gleb

2 Likes
#38

Vaadin 23.3 is just released.