Why Enum instead of Collection in DefaultFieldGroupFieldFactory

Hi,

I wanted to know why do you decided to use Enum instead of Collection to bind and build selects? I think that in order to build a proper Table a collection would be more suitable… I am using a JPAContainer and I wanted to create a table for objects on a one to many relationship, which is automatically generated as a Collection. So I’ll have to do a custom fieldfactory for a use case that I think a lot of people would use if provided by out nativelly.

Thanx
Bruno

Hmm… I think these are wholly separate use cases.

Supporting enums out of the box makes sense as the set of all alternatives is available: it’s just
EnumSet.allOf(MyEnum.class)
.

If, however, you have some arbitrary one-to-many mapping between two entity types, say, a Company that has Employees, without application-specific knowledge about the data model and persistence layer it’s not possible to figure out the set of all Employees to fill the select with, even though we would know what the select’s
value
would be.

Hi,

I am probably missing something here but, using your example, a getEmployees on a JPA Entity, which will usually be a Collection, it is quite easy to have the toString() method with the name of the employee and create a container over those results which would populate any select you want. It is much more difficult to have enum values for every possible value on a one-to-many mapping. It only works for simple classifiers (gender, age group, etc), which are used but not as used as one-to-many generic relationships like your example, the app I am working on ddo not have any relationships where I can do a enum class. So I still think a Field Factory based on a Collection would be much more useful than enums. You can always create a Collection from a EnumSet but not the other way around.

Thanx
Bruno

Hmm. I think your use case is different from what the build-and-bind mechanism of FieldGroup is designed for. If you have a bean/pojo/entity, when you bind it to a FieldGroup the result is supposed to be a set of fields that can be used to display a form for editing the entity in question. For instance, if a Company has a
String name
field, then FieldGroup should output a TextField for changing the name, with the field’s value being the current name. Similarly, if there’s a
Collection employees
field, the intended behavior would be returning a multiselect-enabled select field, with its
value
(selection) being the elements of
employees
, and the
content
(set of all selectable alternatives) would be an application-specific set of all
potential
employees (including those not currently in
employees
). The default field factory cannot know the latter.