My apologies if this has been answered, but I can’t easily find a post that matches. Related is this post about
no VaadinSession during testing . My problem looks similar to issues with detached objects in v6, but really I’m just grasping. This is with version 7.2.7.
My app loads with a login screen, and the user enters information, clicks a button, etc. The Layout in the single UI class has a clickListener that tells the UI class to authenticate the user and load a new user interface. The UI class creates a new VerticalLayout, calls setContent() with it, and starts adding all the new UI bits to the layout.
(Note: with Vaadin 6, after all this happened we would call
.open(new ExternalResource(.getURL())); – I’ve replaced that with a page reload, but am not sure I need it and the exception is happening before I get to that line anyway).
When it gets to adding a Form object (I’ll replace deprecated Forms later if possible), I run into:
[code]
com.vaadin.data.Buffered$SourceException
at com.vaadin.ui.AbstractField.setPropertyDataSource(AbstractField.java:637)
at com.vaadin.ui.Form.bindPropertyToField(Form.java:768)
at com.vaadin.ui.Form.setItemDataSource(Form.java:739)
at com.vaadin.ui.Form.setItemDataSource(Form.java:687)
[constructor of a Panel object]
[/code]Cause:
Caused by: com.vaadin.data.util.converter.Converter$ConversionException: Unable to convert value of type [Ljava.lang.String; to presentation type class java.lang.String. No converter is set and the types are not compatible.
at com.vaadin.data.util.converter.ConverterUtil.convertFromModel(ConverterUtil.java:116)
at com.vaadin.ui.AbstractField.convertFromModel(AbstractField.java:708)
at com.vaadin.ui.AbstractField.convertFromModel(AbstractField.java:693)
at com.vaadin.ui.AbstractField.setPropertyDataSource(AbstractField.java:629)
... 55 more
I’m confused that Strings can’t be converted to Strings by default, but I think something else is going on and is masked by that error. Somewhere in there, I think where the field is getting its locale, there was a null VaadinSession returned from getSession(). Am having trouble narrowing down the error now due to long-distance debugging being so slow, but will look for more information. If this sounds famiiar without more info, please let me know.
Argh, was so distracted by the related issue and wondering why I had null VaadinSession that I didn’t notice that detail in the output. My remote debugging is painful, but I finally see that ‘modelValue’ passed into convertFromModel() is a String array.
Now hopefully I can figure out why that’s happening. There must be some reason it’s happening now but didn’t with v6. Just a hunch – there are 2 getters in the bean item object that return String. We don’t create fields for them in the form, but something is happening so that Vaadin thinks we are, or something, and so is trying to create a converter. If my remote debugging weren’t so slow I’d know instead of having hunches.
No, remote debugging is so slow and unpredictable that I can’t get a good sense of what is going on in V7. Can someone enlighten me about how forms and fields work in v7? The code does this:
BeanItem<Foo> fooItem = new BeanItem<Foo>(foo);
Form form = new Form();
form.setFormFieldFactory(new MyFactory());
form.setItemDataSource(myItem); // <------ exception here
form.setVisibleItemProperties(<list of strings here>);
The ‘Foo’ object has some getters that are Strings (e.g.) and one that returns String. The String
getter is not in my visible properties list and is not handled specifically in my form field factory – in that case super.createField(i, propId, uiContext) is returned.
This worked fine in v6, so either the form field factory was called later in the runtime process
after the visible items were set and so no field was created for the String prop, or else the field was created, not used, and Vaadin didn’t care that conversion between String
and String was a problem,
I’ve changed our form field factory to specifically check for this property id in createField and return null. That’s getting past the error, but I have to do the same for several property ids and it’s very tedious. Would be happy to know from someone else if I’m doing this right or if I should move the setItemDataSource() call after the setVisibleItemProperties() call instead (which would mean moving some other code around as the above is simplified).
Took a quick look in the Form.java class, looks like you should call the setItemDataSource(Item, Collection<?>) method so it only binds to the specified properties. Doesn’t look like the setVisibleItemProperties will affect which fields it attempts to bind.
Form is deprecated in v7 but I honestly have no idea why. From the JavaDocs in Form.java:
[code]
@deprecated As of 7.0, use {@link FieldGroup} instead of {@link Form} for
more flexibility.
[/code]I can understand why they want a way to bind fields without a restriction on layout. There is a good YouTube example on how to use FieldGroup binding. It works great if you have a POJO / Bean object to bind with.
I just wanted a simple way to throw a Form object down with a SQLContainer to do a quick demo with live edits.
It would be ideal if Form could be brought back and made to work in 7. What is even more annoying is having to wrap components in a FormLayout() and then pass that to a Vertical or Horizontal to just do a simple page. I’m converting a lot of legacy apps where my users want it to look like the legacy screens.
I don’t think there is much risk of Form disappearing soon even though it is marked as deprecated - it will be there at least throughout the Vaadin 7.x series. If it meets your needs, you can continue using it at least until Vaadin 8 comes out.
Thanks – this was the best solution for me. Now my earlier question about why it worked in v6 is just a matter of curiosity for me. I should probably have been using this other version of setItemDataSource all along. It must be more efficient to not create fields that are never used.
