Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
[deleted comment]
[deleted comment]
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
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
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
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
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
Original issue reported on code.google.com by
releases...@googlemail.com
on 9 Apr 2013 at 1:19Attachments: