[
https://issues.apache.org/jira/browse/LABS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701761#action_12701761
]
Simone Gianni commented on LABS-351:
------------------------------------
Unfortunately adding an @Consider annotation challenges the system :
- It should target the foundation-beans package, but conversion in handled in
the foundation-conversion package
... Merging the two packages, making conversion a core part of beans?
- In many many places, a converter is searched based on the actual getClass or
getReturnType of methods
... This stems from the assumption that if the property is of type X, then we
can pass its value and use getClass to obtain X.
... When the value is obtained from the handler, the handler will return the
correct Y type instead of X, removing this problem.
- It could easily lead to impossible conversions required to the system
... Check that the annotation is only applied to "generic" types, aka String,
byte[] and streams/readers.
Starting from revision 767690, the conversion system has moved inside
foundation-beans. If everything goes well, foundation-conversion can be removed.
Now, converters must broad their meaning. While they were *<->String, now they
must be *<->*, where the second * is String, byte[] or streams. Obviously, we
don't want to build a "path" of converters, but at maximum two steps, like
String to File to Inputstream.
The special case to *<->String must be preserved, cause it the one used
everywhere the url is built or parsed in web, or where a value is converted for
user purposes.
So, I defined a new GenericConverter<X,Y> interface, and made the Converter<T>
interface extend this interface specializing it for Y=String. I had to redefine
toString and fromString methods to the more generic Y to(X) and X from(Y) .
This will lead to compilation errors in other packages, will fix them later.
In reality, we now have two method, "to" and "from". This had a meaning when
one of the two points was fixed (toString fromString), now they should be two
converters, one going from X to Y and the other from Y to X, and a single
"convert" method. This would anyway be quite a big refactoring, and would also
introduce the concept of "one way only" conversions, which I'd really like to
avoid.
> [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]
