Vaadin UX Best Practices Webinar

Join Vaadin’s very own Marlon Richert and Rolf Smeds (UX designers @ Vaadin) who will show you some common UX problems in Vaadin apps – and how to easily fix them. You can post your questions below, thank you!

Webinar takes place on Thursday March 19th 2015 @ 2PM CET

embedyoutube=xXFoJ_rOX8Q

question about read-ony mode for presentation mode - what if form contains a lot of select, radio options and checkBoxes components?

On toggleing enabled states of buttons when editing a form.

Are there any plans to support this better in vaadin?
We’re trying to follow this pattern but we’re having the following difficulties:

  • Its quite tricky to implement at the moment using fieldgroup.
  • It requires a server round trip on every field change which causes a lot of progress bar flashes on clients with poor internet connections. This is particularly bad when listening to TextChangeEvents.

Ideally we’d like to see it built-in to the field group API and also have to option of carrying out client-side validation.

  1. How one can set validations for grid inline row editing?
    (e.g. Say there are some required fields/ regex based inputs/ date fields and exclusive fields)
    Exclusive fields where if field1 is filled then field2 should be empty and vice-versa
  2. read-only to edit mode switch increses click for users?

what is best way to show data-grid which has another data-grid
(grid inside grid) or (grid inside tree)

Well, you can’t put a Grid (or any other Vaadin component) inside a Grid cell. Hypothetically, I suppose you could put a Table or a Grid inside a cell in a Table, but that sounds like a terrible idea, at least out of a performance perspective.

Even putting technical considerations aside for a moment, I’m a bit skeptical to the idea from a UI design point of view also. Perhaps there is a better way to design the UI than nested tables/grids? It’s a bit hard to make any concrete suggestions without knowing the details, of course.

If the outer grid only has a handful of rows, perhaps you could use an Accordion for that instead?

Also, I believe the Grid component will get a row grouping feature in some future version, so perhaps that would be a suitable solution for you, once that is released?

  1. I believe this page may have the answer: https://vaadin.com/book/vaadin7/-/page/components.grid.html#components.grid.editing

  2. If you mean that you would like all rows to be editable by default (instead of having to switch each row to edit mode explicitly), I’m afraid that is simply not possible with Grid (as opposed to the Table component), since it only supports row-based editing.

Hi Eric. As for the difficulty of listening to field changes using FieldGroup, I actually created a feature request about this a couple of years ago: http://dev.vaadin.com/ticket/10298 . Ideally, I would also like to have some mechanism for binding buttons to the fieldgroup so that their states could be automatically toggled, but even just an easy way to listen for changes in multiple fields would be nice. If you have a pro account you can go in and vote for the feature. Or you could write your own feature request, as Marlon suggested in the webinar.

Eric, Rolf, you should definitly check out
AbstractForm in Viritin
. By using it (and MTextFields instead of raw TextFields) you’ll get exactly this kind of behaviour for free. And indeed, as Eric mentioned, it is way too tricky to be implemented with Vaadin currently. Until this is fixed in core Vaadin I can only recommend to use AbstractForm (I’m pretty happy about it currenlty) and complain via githubt if it don’t work well enough :slight_smile:

The AbstractForm also fires ValidityChangedEvents if you wish to execute some custom logic when validation status changes.

The client vs server side validation is always tricky. Pros for server side is that we can never trust client side only validation and some things are just impossible on client side (e.g. check duplicate usernames). To play down the efect of slow server side visit on bad network, you could try using push connection. Especially WebSocket communication helps a lot with e.g. mobile networks that have rather big latency. Also, sometimes it is only about too prominent indicator about the ongoing communication, changing the delays for the indicator should be considered if you have lots of users with slow connection.

cheers,
matti

Thanks for your replies Rolf, Matti.

I’ve had a go with AbstractForm that and the other approaches available in Viritin. It works well, but we don’t use the ‘BeanItem’ approach very often and prefer to work with the data binding api directly. Websockets aren’t an option for us at the moment.

Thanks for the tip about changing the delays for the indicator. Worth considering.

Hi Rolf

Thanks for the immediate reply. Can we put grid under the row?
The requirement is to open child table just below the row clicked inside Master Table.
As you click next row, its child table will be opened just beneath the row clicked.

Is the row grouping exactly means the same? (I dont know)

Can you suggest any alternatives for master-child tables?

I don’t really know what the row grouping feature in the Grid is going to be like, but I suspect that’s the child rows will need to have the same set of columns as the parent rows, kind of like a Vaadin TreeTable.

Speaking of TreeTables, in case the limitation mentioned above is ok, you might want to try using a TreeTable with two levels. Then you can expand the first level (parent) rows to display its child rows.

If this is not the case (i.e. the child table has a different set of columns), I think your best options are:

  1. Skip the “directly beneath” requirement, and just have two separate tables (side by side, or one below the other), and populate the child table when an item in the parent table is selected. This would probably be the easiest solution.
    or
  2. Don’t use a Table or Grid for the parent rows, and instead roll your own scrollable list (e.g. a Panel with a CssLayout) with components that contain child tables that are revealed when they’re clicked. If you dont’ need lazy loading, this should be pretty easy. The parent rows could be implemented e.g. as HorizontalLayouts. Use specific widths and/or expand ratios on the components to make sure the “columns” in HorizontalLayout line up.

Hi,

Just had a time to actually watch the webinar, great stuff! And based on the raised discussion, really valuable for our users.

Couple of tips/notes that I wrote

2:00 (prominent primary action): To implement the primary button, you typically want to always to exactly the code snippet presented. Although this is just three lines of code, you should create a PrimaryButton class to your project to abstract this (or just drop in Viritin that has this class :slight_smile: ).

15:00 (toggling save/cancel/delete based on the state): As discussed above, try using AbstractForm from Viritin. I have spent a lot of time to that and I know that implementing this may be quite tricky with plain Vaadin. So I’m confident that AbstractForm helps a lot to implement this kind of forms.

33:00 (modifying UI based on input): Not that much directly related to the topic, but Rolf is discussing about setImmediate method when using value change listeners. That used to be needed previously, but not anymore (since 7.3 IIRC). Nowadays when you directly add a value change listener to any Field component, it implicitly becomes “immediate”.

Eric, I’d like to understand our users better, so, don’t you have any domain objects or DTOs in your application or why do you want to work with Item-Property thingies directly? In my various demo applications I’m pretty much always trying to hide those if I can (work with just DTOs).

Sanket, there is actually a customer sponsored feature in works for the next version of Grid that might be exactly what you want. I didn’t yet find a public ticket about it, but the feature been so far called “details row” or “expand row”. The idea is that you could get an overlay right below the selected row where you could add any component you want. Once we get 7.5 out I think you could add your dependent Grid there or even the whole “detail form” to this slot.

cheers,
matti

Big thanks for your input, Matti! AbstractForm seems awesome - apparently I’d completely missed that Viritin/Maddon had that kind of feature. Also good to know about the “details row” feature planned for Grid, let’s hope it gets implemented.

Matti, We use Viritin, sometimes directly sometimes more as inspiration. It’s been very useful just looking through the code on github. I would love to hide the Item and Container APIs as well as, and sometimes do take the same approach as you. In other cases I like to keep things clean and consistent. Using a pojo as the id in a cotnainer can sometimes seems like a hack and sometimes the UI model needs properties that don’t map onto the pojo or its nested properties. Using the Item API directly gives us a lot more flexibility in how the properties are exposed and we can easily add derived properties and implement other behaviours which we can’t get from BeanItems. The more behaviour we can drive through Vaadin’s Container/Item/Property abstractions, the less gymnastics we have to do since we’re taking full advantage of binding. This also helps isolate behaviour in the models and presenters which are easier to test.

We only use our DTOs to set up the initial state of our UI models and updates to the domain model is all done through commands. This leeds to some extra mapping from DTO->UI Model->Command but we use groovy so it isn’t much hassle and we benefit from the looser coupling.

Hi,

You are right in that sense that the domain model seldom matches excactly with the model needed in UI. Even then I nowadays seldom use the built in utility classes in Vaadin (PropertySetItem, IndexedContaienr etc). With the help of IDEs I find it actually easier to create a separate domain classes for UI where yo e.g. has some custom properties and hide others (even though I have 7 years experience developing the core and thus know our Container-Item-Property stuff maybe even too well). This is why I’m nowadays heavily promoting usage of basic beans and JDK collections with Vaadin, that it the universal JVM API that is trivial to adapt to pretty much every library and jvm language.

Most often I can avoid using custom Items or custom domain objects created for UI only just by configuring components. E.g. with Table creating a generated column instead of the raw property is really easy (especially with
the typed version in Viritin
:slight_smile: ). For Select components I have added
CaptionGenerator

concept. IMO, both of these improvements should definitely be added to the core as well and there is still lot of room for improvements on this area.

Big thanks Eric about your valuable insights!

cheers,
matti

I have been struggling to find a way to implement a Value Change Listener for the Grid without success and I can not find documentation or examples about this.

Is there a way you could help me with guidance as to where to find this solution ?. So far is the only thing I do not find on the GRID

Jorge, I think your question has nothing to do with this topic, thus I’d suggest to ask it in a separate thread.

cheers,
matti