I’ve looked through the forums for a deffinative answer to this, and also searched wider via Google, but all of the threads/sites that seem most like my query have had no satisfactory responses. If there is a thread/site that answers my question then applogies for repeating things, and can someone point me at it
My problems is really very straighforward and involves just about the most common data structure imaginable (after flat structure of primatives). I have a bean with two String fields, and one Collection field. That Collection field is of a second bean type, itself with two String fields and a Collection (with just String fields in this time). What I want is the definative, Vaadin best practice, way of presenting this data structure to the user in a form-like UI that allows editing of the String fields, and adding and removal of the Beans in the collections.
In my head I imagined TextFields would be bound to the String fields (this seesm to be the default behaviour) and some sort of Tree or Tabbed component bound to the collections (nope, default behaviour is a TextField???). Now it seems to me that a nested data structure like this must occur in virtually every non-trivial web app, so there must either be out-of-the-box support for it, or a well established pattern, I just can’t find anythign in the Tutorial, the Book or the forums.
I’ve tried creating a Form for the top level bean and using a FormFieldFactory to identify the Collection field. Now I’m not sure what to return for the collection; a collection of forms? how would these be displayed sensibly? Then I thought maybe I could return a Form using a Container as the datasource, but forms only take an Item as a source. So before I go runnign off creating some convoluted solution I thought I check with the community; Can someone please help?
I’ve had the same question a while ago. I remember that i also did not find an ‘elegant built-in’ solution in Vaadin, so I designed my own ‘Form’, which is just a layout with TextFields, CheckBoxes, … and i did the mapping (from the POJO to my Form) myself. So basically, i wrote a commit()-, a discard()-, a setValue()- and a getValue()-method and that’s it.
Sorry if you were expecting a more elegant solution…
Please see p118 of the Book of Vaadin for your answer relating on how to create the list dropdown. What you have to return is a Field, so perhaps a custom Field with an edit link within it somewhere would do the trick.
Thanks for the responses. Bit bemusing that a product that in many other respects is so polished, can’t cope with simple nested data structures, seems like a glaring oversight to me.
I have decided to pretty much do away with the whole Vaadin approach with respect to editing my beans, and go with the solution suggested by Jan De Beule , a single custom component that does all the UI and do all the data binding myself.
I had the same reaction, mostly because my previous endeavour involved just that (my company built a product that did just that, arbitrary nesting of display/edititing widgets based on a user-defined web-editable metamodel).
I believe that a Roo plug-in that would generate such nested forms is something Vaadin needs to look at extremely seriously. Otherwise Vaadin will see its lunch being eaten up by the Roo-GWT plugin. Scaffolding (meaning automatic generation of a reasonably useful interface from a data model) is a must.
I believe that the core Vaa duct must have a well-defined standards compliant container, and a scaffolding solution.
For those that are interested I’ve figured out how I’ll do this, and my solution might be applicable to similar data structures:
I have a single top level component which manages everything. In the component I have a custom Form for each bean type in the data hierachy. These Forms are attached to standard BeanItem instances. The Forms define custom FieldFactories which present Tree components for any Collection type fields in the underlying Bean. The Tees are populated with the Collection data using BeanItemContainers. The Tree’s have click listeners which call back into the top-level component. When a given Tree’s listener fires it replaces the BeanItem in the relevant Form instance with the selected item. I then provide some collection management buttons (add, remove) for each of the Collections in each Form. The UI looks OK, not as ‘sexy’ as I’d like, but its workable. I’ve yet to get updating working, but I don’t think this will be insurmountable.
By using Trees in the way I have, i.e. rather than the ‘value’ of the Tree being a single item the ‘value’ is now the entire collection, the default commit mechanism breaks. Essentially the Vaadin framework tries to commit the currently selected value in the Tree back to the datasource, my datasource is a container and trying to set a single item into a container is invalid. In order to work around this I create an new Tree item called ‘UnsettableTree’ which overrides the setValue() method with an empty implemntation, this preventts any changes to the selected value being written back to the datasource. Any updates to the Tree now have to be handled manually, so I override the commit() method on the top level Form (the one corresponding to the root of the hierachy) and extract the data from the Trees directly, and then persist everything via my database layer. If I now turn on writeThrough on all the Forms everything works more or less as expected.
The only remaining issue is that the Forms don’t update their displayed values for the Collections unless I manually replace the top level datasource with one created from the manually extracted Form data, I do this inside the overridden commit() method. This means that despite writeThrough being true I still have to call an explict commit to ensure the displayed values are in-sync with the datasource values - still this isn’t too much of an issue.
