|Re: Custon type in &lt;xs:list&gt; [message #1413264 is a reply to message #1413252]
||Thu, 28 August 2014 07:05
| Ed Merks
Registered: July 2009
On 28/08/2014 8:42 AM, Gordan Vosicki wrote:
> Thanks Ed for your proposal, this might be a solution.
> Just a silly question:
> As the XSD file has to be modified anyhow until there is a way to
> define additonal things (like ecore:type) outside the original file
> (like in JAXB),
This relies only on an xmlns declaration and that declaration must be in
the XSD itself to be used there, so no. Given the nature of where these
annotations can appear (i.e., in all kinds of nested content) it's
significantly pretty tricky to define an external mapping and the
implementation of an authoring tool for doing so is also a significant
> I could also simply replacee the xs:integer and xs:positiveInteger
> types by xs:int or xs:long.
> Would the XML read/write functions still work if I made this simpler
> change ?
Yes, in the end this only affects the conversion of strings in the XML
to Java instances so assuming the strings conform to the value range
implied by those Java types, it should all parse and serialize in the
> Another point:
> These lists have potentially hundreds of thousands of elements.
> I would prefer to use collection classes containing arrays of simple
> types instead of objects (int instead of Integer). We already have
> such classes, which actually implement java.util.List, and it would be
> easy to add support for EList.
I see. It's always possible to use your own custom data types...
> Is there a more elegant way to do it than to modify by hand the
> generated factory methods ?
> public List<BigInteger> createFaceTypeFromString(EDataType
> eDataType, String initialValue);
> public String convertFaceTypeToString(EDataType eDataType, Object
Somewhere you need to have had written code. You could do that in
another model and specify that model's type as the ecore:type (or define
that other model as an XML Schema and change the actual schema type= to
use that model's simple type).
> Is there anything else which has to be done for this, I personally
> hate modifying generated code ?
Yes, some folks have a strong aversion to that. At some point I'll look
at generalizing the generation-gap pattern and supporting it more
broadly, but that's also a significant undertaking (complicated by the
trickiness of finding custom overrides automatically in either source or
on the classpath)...
Powered by FUDForum
. Page generated in 0.01662 seconds