Fieldgroup row - col spans


Still trying to customize a field group with dozens of fields, and still hitting issues. Seen that I’m not the only one with this kind of issue.

If you look at the image below, you see a “comment” field with 4 rows on the second column. No row spanning possible so if you look on the left there is a blank area.

What is sad is that with a grid layout it is possible to span col & row. Plus, you can do cool stuff with a grid layout like drag n drop of fields on line and column. And you can adjust heigth and weight of any component with the mouse.

The more we try to use fieldgroup, the more we think that it will never reach the level of features of grid layout, and these features (span, drag, resize) are not really options in a (aspiring) wysiwyg editor.

I would have a simple advice : why write tons of code in FieldGroup to mimic what grid layout is already doing good ? This race will never end IMHO.

That might be a hefty refactoring, but the visual behavior of FieldGroup should just be the GridLayout genuine code. With some additional code to ensure that all actions like e.g moving a component into another column is restricted to be dropped in the field group area.

We studied how to get rid of field groups everywhere and replace with grid layouts, and it fact there is not no much trouble doing so. The main issue is that when Studio add a component after creating a new entity property it does not give it a meaningful name (eg “textField”), so you cannot inject it properly. I open another ticket for that.



Thank you for the idea. Actually, we use FieldGroup not only because of captions layout, it supports additional platform functionality: attribute security and dynamic attributes. If you use GridLayout you will not be able to use these features out of the box. In your case, if you really want to write a fine-grained form with fixed positions of fields that does not support dynamically hidden fields I’d recommend to use GridLayout. GridLayout and FieldGroup components are not substitute for each other, thus we will try to improve FieldGroup as much as possible.

Nonetheless, I think that “Generate GridLayout form” option would be useful.

About attribute security, not sure I understand : if I set a text field in a grid form for a property that I do not have access to because of my user profile, I cannot see it nor write it right ? Did not test it, but this is what documentation and reading code of DataManager tell me, am I wrong ?

If I’m not, and I think so because that would be a security hole you guys couldn’t have missed, what are the additional security features provided by field group over other data aware components ? Field group doc is mute on that. In fact, neither in XML nor in Studio screen I can see something about security for field group. I think it’s simply relies on DataManager security like any other field.

About dynamic attributes, however this is a clear point. We plan to test them in some time, but in that case we will probably restrict field groups especially for them somewhere in the grid form.

NB : do you plan to add dynamic attributes to DataGrid also ? Because we quite like this component and thinking about getting rid of most of our tables in favor of it.

In the end, except maybe if there are other specificities to FieldGroup than the ones mentioned here, I still think that FieldGroup should be implemented from the graphic+presentation perspective as a genuine composition of a grid layout container and a set of labels+fields components. And voila you have the same feature level than grid layout.

Specificities of FieldGroup visual implementation causes specific problems :

And these are only reported ones. The real problem is that for spanning issue for instance, there is practically no workaround : you have to drop FieldGroup for something else, and grid layout is the most flexible.


At the moment, I see only one major problem in comparison to GridLayout - col/row spans.

In practice, if you use col/row spans in forms and apply security with hidden attributes to GridLayout you will see a lot of empty space left in your layout, that’s why we don’t use it for forms in our UI screens.

As for attribute security, there is no principal difference, but FieldGroup enables you to switch editable for all the fields with single call fieldGroup.setEditable(false) without switching editable for all the children. Also, it supports TOP / LEFT alignment for captions that cannot be implemented in GridLayout in a generic way, e.g. if you hide UI component then FieldGroup will hide caption too. Since 6.8 version it shows additional column with context help icons:

So, FieldGroup is aimed for forms that behave in a generic way and can be extended with dynamic attributes while GridLayout is a simple layout component for custom forms.

As I know, DataGrid already supports Dynamic attributes. Unfortunately, we do not plan to introduce them for GridLayout.

I got it. In fact with 3 things, FieldGroup would be just great : 1) col/row span 2) drag fields over columns & lines 3) resize columns with mouse. The last one misses for grid layout too.

It’s very frustating for a junior dev used to another GUI editor to see the field group just before its eyes without being able to do anything on it visually except resizing.