Generate JS-mapping with default values

[martinpfannemueller]

trafficstars

Referring stackoverflow question: http://stackoverflow.com/questions/29256036/jsonix-get-restrictions-and-default-value-for-properties

[highsource]

See also highsource/jaxb2-basics#26.

[st-sloth]

Hi, is there any change of default attributes being supported?

[highsource]

Didn't work on it, sorry.

[st-sloth]

That's okay. I also apologize for misspelling the question :woman_facepalming: I meant to write "is there any chance". I forked the repo and tried to add this but I've never worked with Java and this change turned out to be not that trivial, so I didn't succeed. I could however add processing for default in jsonix, if the mappings would include it.

I apologize again for being a nuisance, just wanted to know whether this feature has a future.

[highsource]

No need to apologize.

I've checked the code, the Java part should not be too hard to implement.

[highsource]

I've implemented the first draft of defaultValue generation. Please give it a try and let me know if it works for you.

[st-sloth]

Wow, @highsource, thank you so so much, this is amazing!!! :tada: :heart:

It certainly works for me. There are minor issues, but in my case there are workarounds: defaultValue does not appear on attributes that

1. have neither type attribute nor simpleType element. In mappings they have typeInfo: 'AnySimpleType';
2. refer to external simpleType with enumeration. Internal simpleType with enumeration or simpleType with pattern, both external and internal, work. But also in case of external simpleType with pattern, typeInfo is missing in the result;
3. also from the test schema - while attribute of type xs:NCName has defaultValue, attribute of type xs:IDREF, which in turn refers to xs:NCName, does not.

I added several cases to the test schema in my branch.

---

There is also some weird behavior not related to default values - if attribute is named package, then in the mappings it is prefixed with an underscore, though it is unchanged in attributeName:

{
  name: '_package',
  attributeName: {
    localPart: 'package'
  },
  type: 'attribute'
}

is it by design or an issue?

---

I'm yet working on support of defaultValue in jsonix, and will make a PR in some time.

[highsource]

Please file separate issues for individual problems. I'd be grateful if you send PR with reproducing test cases (please use tests/issues/src/main/resources/schema.xsd for that).

1. anySimpleType - not quite sure about types here. Probably just copy the string value.
2. Not sure what you mean by "external simpleType".
3. ID/IDREF/IDREFS are a special type of beast.

[highsource]

For your other question about _package see #82.

[st-sloth]

Created the PR for extending the test schema.

1. anySimpleType - not quite sure about types here. Probably just copy the string value.

It does seem to be the most logical and expected behaviour.

2. Not sure what you mean by "external simpleType".

An attribute declaration that references its type via type, like this. In contrast with "internal" that is inside the attribute declaration, like this.

3. ID/IDREF/IDREFS are a special type of beast.

Which is totally fine by me :) There is no problem here, just wrote down accidental observation

---

Please file separate issues for individual problems

Do you mean the _package thing? If so, it's not much of a problem, just thought it would be more appropriate to ask about it on the side of an ongoing discussion rather than create whole another issue. Which probably was a mistake. Do you want me to create an issue about _package?

If you meant something other than _package, I'm afraid I don't understand what is that.

[highsource]

Thank you, I'll take a look at it as soon as I have time.

With "separate issues" I mean one isse per points 1, 2 and 3. ok, 3 is not relevant so no it's just points 1 ("Support default values for anySimpleType") and 2 ("Support default values for named simple types").

Basically I'd be gratefult to have several small specific issues vs. one big "kill em all" generic issue.

[st-sloth]

New issues are created.

I truly appreciate it a huge lot that you look into this! Infinite thanks!