[
https://issues.apache.org/jira/browse/LABS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701763#action_12701763
]
Simone Gianni commented on LABS-351:
------------------------------------
Core part is done, and a test on @Consider(Date.class) on a String field seems
to be working correctly. Now we need the objects to map to, like File, Image
etc.. and the converters to streams and byte arrays.
> [beans] @Consider annotation
> ----------------------------
>
> Key: LABS-351
> URL: https://issues.apache.org/jira/browse/LABS-351
> Project: Labs
> Issue Type: New Feature
> Components: Magma
> Affects Versions: Current
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: Current
>
>
> Some data types are straightforward, like Integer or Date. Some others are
> not, like String or byte[] or InputStream.
> Currently Magma ties converters to data types, that means that there can be
> one and only one String converter or ByteArrayConverter. On the opposite, for
> those datatypes, there should be a way to tell Magma that it is a byte[]
> containing something, obviously something compatible with the byte[] data
> type, like a file, or an image etc..
> Magma does not have a @Converter annotation which could be a solution.
> It could be possible to hook it into validation annotations, but it's ugly.
> A more semantic solution could be the @Consider(type) annotation. Using such
> an annotation, the user is telling Magma that despite that field being X it
> should eb considered something else Y. This would mean having a converter Y
> <-> X in addition to the Y <-> String normal converter.
> This second conversion Y <-> X would happen as the last step inside the
> handler, because all the beans infrastructure should consider the field as
> being Y and not X. "mock" Y types could be created for common types like
> "DataFile", "ImageFile", "RichText" and the like.
> That means that validations are applied to Y instead of X, so specific
> validations for DataFile could be the size and the mimetype, while for an
> ImageFile it could be the image size.
> Another good use of such an additional flexibility point is dealing with
> legacy beans where Strings are used to contain other data, like a number, and
> wanting to apply to them number specific validations and inputs, "remapping"
> the type to Integer would work, cause an Integer <-> String convertor already
> exists. Obviously this cannot be applied to any kind of conversion, but
> String, byte[] and streams should be enough to cover more than 99% of cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
