Core: introduce AutoConverter as alternative of omnifaces.SelectItemsConverter

[tandraschko]

i talked with my colleague today and he developed an converter in our company very similar to https://showcase.omnifaces.org/converters/SelectItemsConverter

TBH i dont like the toString approach, therfore i'm think about introduding something like:

        <h:selectOneMenu id="iterator" value="#{selectItemsBean.selectedEntity}">
            <p:autoConverter var="entity" itemValue="#{entity.id}" />
            <f:selectItem itemLabel="Choose item" noSelectionOption="true" />
            <f:selectItems value="#{selectItemsBean.exampleEntities}" var="entity" itemLabel="#{entity.value}" itemValue="#{entity}" />
        </h:selectOneMenu>

so you specify the itemValue as "entity" in selectItems, the converter will convert entity<>entity.id and vice versa

You could also register it globally via:

        <h:selectOneMenu id="iterator" value="#{selectItemsBean.selectedEntity}">
            <f:selectItem itemLabel="Choose item" noSelectionOption="true" />
            <f:selectItems value="#{selectItemsBean.exampleEntities}" var="entity" itemLabel="#{entity.value}" itemValue="#{entity}" />
        </h:selectOneMenu>

@FacesConverter(forClass = MyEntity.class)
class MyEntityConverter extends AutoConverter<MyEntity> {
      @Override
      public String toString(MyEntity obj) {
            return obj.getId();
      }
}

Not sure the idea is perfect - thoughts?

it could also pickup objects from e.g. the picklist modell and other PF components.

[melloware]

I like this idea!

[Rapster]

So at worst, you end up having the same things as "If your entity can't have a good toString() implementation" in omnifaces showcase, at best we could have a JPA converter, but not sure I follow the autoConverter approach here, what's the added-value?

[tandraschko]

A JPA converter creates a query, the autoConverter just uses the loaded datasource of the component itself (selectItems, or PickListModel)

OmniFaces doesnt support picklist and we force to define a id field, not just magic toString.

[fcorneli]

the autoConverter just uses the loaded datasource of the component itself (selectItems, or PickListModel)

So you reload the entire list for each conversion? Isn't that rather expensive?

[tandraschko]

JSF will do it anyway

[fcorneli]

mmm... yep, indeed.

[fcorneli]

@tandraschko Will JSF also restrict the selected item to what is available within the loaded list? I.e., first time we have {A,B,C}... hence it should be impossible to select, for example D (even when you mess with the request)?

[tandraschko]

normally yes but thats offtopic

[tandraschko]

what about the name? it exactly uses the datasource of the attached component to "convert" or "serach" it therefor "SelectItemsConverter" wouldnt fit as we also support e.g. PickList model

[Rapster]

A JPA converter creates a query, the autoConverter just uses the loaded datasource of the component itself (selectItems, or PickListModel)

Not what I had in mind, you're talking about the converter based on toString method, my proposal for JPA is instead of that, the impl could be based on @Id/@NaturalId/etc (this should be done in omnifaces then)

Regarding PickList, omnifaces have a solution explained here: https://showcase.omnifaces.org/converters/ListConverter. Again, if you don't like toString you can easily override getAsString from omnifaces

I like the way you can define your Converter#getAsString() declaratively through AutoConverter#itemValue (if i understand well your sample), but again, I don't expect users to write everytime <p:autoConverter ... /> but instead create their own converter and then use with <o:converter />

So far based on the issue description, I don't see what PF could bring more to the existing solutions