[ http://issues.apache.org/jira/browse/JAXME-47?page=comments#action_57621 
]
     
Nacho G. Mac Dowell commented on JAXME-47:
------------------------------------------

This error can be solved adding a few more cases to getXMLField when it is a 
simpleType (I forgot to add this in the bug description...) like this:

if (!pController.isComplex()) {
        Object o = pController.getSimpleTypeSG().getInitialValue(pSource);
        if (o == null && pDefaultValue != null) {
          if (runtimeType.equals(StringSG.STRING_TYPE)) {
            o = "\"" + pDefaultValue + "\"";
          }
          else if (runtimeType.equals(IntegerSG.INTEGER_TYPE)) {
            o = "new java.math.BigInteger(\"" + pDefaultValue + "\")";
          }
(......DecimalSG...)
          else {
            o = pDefaultValue;
          }
        }
        if (o != null) {
          jf.addLine(o);
        }
      }

The thing is that I don't know how to initialize it when its runtimeType is 
Object (for example for the union type where it is not always possible to 
"solve" the runtimeType). If the type couldn't be deduced then it would 
probably be safe to consider it as a String. What do you think?

I have a proposal though: Would it be possible for the JS framework to be able 
to "initialize" a new field according to its type? I think this would be much 
clearer and IMHO it would enhance JS.

Another thought I had is that it would be nice if there was a properties file 
(or whatever) which maps xs to java object just to keep everything more compact 
(and easier to find...). Truly I don't know how this could be 
acheived or if it would be useful at all. Just a thought.

Regards,

Nacho



> When using default values initialization of vars doesn't work for all types
> ---------------------------------------------------------------------------
>
>          Key: JAXME-47
>          URL: http://issues.apache.org/jira/browse/JAXME-47
>      Project: JaxMe
>         Type: Bug
>   Components: JaxMe Core
>     Reporter: Nacho G. Mac Dowell

>
> Consider the definition of the following element:
>     <element name="elt">
>         <complexType>
>             <attribute name="a" default="1" type="decimal" />
>             <attribute name="b" default="0" type="hexBinary" />
>             <attribute name="c" default="none">
>                 <simpleType>
>                     <union>
>                         <simpleType>
>                             <restriction base="NMTOKEN"/>
>                         </simpleType>
>                         <simpleType>
>                             <restriction base="anyURI" />
>                         </simpleType>
>                     </union>
>                 </simpleType>
>             </attribute>
>             <attribute name="d" default="1" type="integer" />
>             <attribute name="e" default="-1" type="nonPositiveInteger" />
>             <attribute name="f" default="1" type="positiveInteger" />
>             <attribute name="g" default="1" type="unsignedLong" />
>         </complexType>
>     </element>
> When compiling the schema we get the following result:
>   private java.math.BigDecimal A = 1;
>   private byte[] B = 01;
>   private java.lang.Object C = none;
>   private java.math.BigInteger D = 1;
>   private java.math.BigInteger E = -1;
>   private java.math.BigInteger F = 1;
>   private java.math.BigInteger G = 1;
> having multiple compile errors.
> Further investigation is required to determine exactly all cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to