Generic property converter

[GoogleCodeExporter]

For my project I created a Converter which converts by a given property-name 
using reflection using a collection of instances. 

I use this kind of converter for my view-param conversion to make them more 
userfriendly, then just converting by an unique id. In most of my 
jsf-components in combination with lazy retrieved remote entities. 

This maybe usefull for others and you like the idea for omnifaces. Code is in 
attachement.

It depends on 'org.apache.commons.lang' and 'org.apache.commons.beanutils' for 
reflection methods.

Original issue reported on code.google.com by releases...@googlemail.com on 9 Apr 2013 at 1:19

Attachments:

• ByPropertyConverter.java

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

In Constructor the null checks of cause should not use the "this" qualifier and 
"propertyType" needs to be set.

Original comment by releases...@googlemail.com on 19 Apr 2013 at 1:31

[GoogleCodeExporter]

The proposal is sound, but I haven't seen useful real world use cases for this 
yet, at least not which is already covered by SelectItemsConverter, 
SelectItemsIndexConverter, ListConverter and ListIndexConverter.

Maybe if this issue retrieves more votes. Note that commons beanutils can 
easily be replaced by standard `java.beans.*` API (which is currently also used 
by taghandler.RenderTimeTagHandlerHelper and util.Json in OmniFaces).

Original comment by balusc on 2 May 2013 at 3:38

[GoogleCodeExporter]

As mentioned this can be usefull for view parameter conversion. For other 
conversions I also dont see a use case. 

For instance currently I am implementing prettyfaces and my categories and 
product view-parameter where just identified by simple integer ids which is not 
nicely readable.

So I just switched converter to my property converter (also have a remote lazy 
load version) and provided the new unique property name "seoName" and I am 
finished.
Not i have nice urls including readable parameters.

Original comment by releases...@googlemail.com on 7 Aug 2013 at 8:15

[GoogleCodeExporter]

I see that the list of available values is hold as converter 
attribute/property. This is not efficient in case there are many of them. The 
right way would be to let it call a service method. This in turn tight-couples 
the converter with application-specific service layer. Something in line of 
this idea has been answered before: http://stackoverflow.com/q/17343032/157882

I'm closing this off as "WontFix". 

Original comment by balusc on 9 Aug 2013 at 3:38

• Changed state: WontFix

[GoogleCodeExporter]

Of cause this can be abused if someone tries to load complete database. (I know 
there are many people doing things like this.)

I am holding the values as a list since using it in a crud application with 
lazy-loading and pagination support. There is no reason in not holding the 
small list since data was already loaded in the bean-scope and values will 
remain there (LazyDataModel).

I also have an identical property-converter version without list for retrieval 
from a service method for other use cases. But this would be coupled to tightly 
to the application as you said.

Example: 

All Orders of a User are shown in a table. In each row is a <h:link> with the 
order as <o:param> and the associated converter targeting a new site where 
order can be seen or edited. 
We lately switched from identifying an Order by database "id" to a generated 
"ordering number " and with the support of generic property converter it was 
done within a few minutes.

Original comment by releases...@googlemail.com on 23 Nov 2013 at 4:59