TextField string width fitting: confusing fragment in the Book of Vaadin

Hi,

the following fragment from the Vaadin’s bible at
https://vaadin.com/book/-/page/components.textfield.html
at
5.9.2
brings a lot of confuse and waste of time to developers:


There is no standard way in HTML for setting the width exactly to a number of letters (in a monospaced font). You can trick your way around this restriction by putting the text field in an undefined-width VerticalLayout together with an undefined-width Label that contains a sample text, and setting the width of the text field as 100%. The layout will get its width from the label, and the text field will use that.

There is an outdated illustration to that proposal, that one can find in the "
Book of Vaaadin Examples
" at
http://demo.vaadin.com/book-examples/book/?restartApplication#component.textfield.widthfitting

It simply doesn’t work if one runs it under Vaadin 7.x and Valo theme (didn’t try it with elder ones). In particular, if your label’s string length is quite short, say = 10, the texfield’s width is far wider than it should be. In such form it cannot serve as a solution for text field string width fitting.

Could the information in Vaadin sources (
The Book of Vaadin
&
Book of Vaaadin Examples
) concerning text field string width fitting be complemented with a more comprehensive solution, or be removed to avoid disorientation?

Is there an up to date alternative way to perform text field string width fitting? Seems that it is evident to have such feature among the essentials.

Thanks!

Hi,

Yeah, the trick doesn’t work anymore, and I haven’t yet investigated if there is another workaround.

There is
#5986
about using setColumns(). As far as I know, HTML “cols” attribute should work for the purpose, but the method doesn’t use that, but instead sets the em width, which gives rather unwanted result.

I’m currently on vacation, so can’t look into this right now. I’ll get back to this hopefully in a few weeks.

Thank you for the swift response,

surely, the setColumns() method mixes the things up too. It’s current implementation is quite useless, and brings as you’ve justly mentioned, to “rather unwanted results”. The filling up of such “little” gaps throughout the API is much, much more valuable than a fancy WYSIWYG Designer from a real world developer’s point of view. The devil is in the details, as they say.

An updated trick could be tried as a hybrid solution that uses the initial proposal as a basis from
http://demo.vaadin.com/book-examples/book/?restartApplication#component.textfield.widthfitting
together with the following fragment:

SizeReporter sr = new SizeReporter(label);
sr.addResizeListener(new ComponentResizeListener() {
  @Override
  public void sizeChanged(ComponentResizeEvent event) {
    labelWidth = event.getWidth();
    tf.setWidth((labelWidth + (tfRLPadding + tfBorderWidth) * 2) + "px");
    box.removeComponent(label);
  }
});

It involves SizeReporter add-on (
https://vaadin.com/directory#!addon/sizereporter
), where tfRLPadding and tfBorderWidth are text field’s css right/left padding and border width respectively. The combined trick looks even more heavier, but it works.

Cheers!

OK, I examined the trick and looks like the VerticalLayout width logic works differently nowadays, so that the trick can not be used. A component with relative size (100% width in this case) can no longer shrink smaller in a VerticalLayout than its natural default size, and TextField’s natural default size is defined in the browser. It’s rather large; some 200px or about 15 em at least in Firefox.

So, for now, your trick could be the only way to accomplish the task.