Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No error on using "ViewID" instead of "ViewId" in targets section #9

Open
pubmikeb opened this issue Jul 3, 2020 · 2 comments
Open

Comments

@pubmikeb
Copy link

pubmikeb commented Jul 3, 2020

Investigation the issue #7, I've paid attention there is no error when using ViewID instead of ViewId:

"myTarget1": {
	"viewID": "target1",
	"viewLevel": 3,
	"viewName": "Target 1",
	"viewPath": "webapp.view.target1"
},
"myTarget2": {
	"viewId": "target2",
	"viewLevel": 2,
	"viewName": "Target 2",
	"viewPath": "webapp.view.target2"
}

Although JSON is a case sensitive.
What's really strange, if I write ViewName instead of viewName, I'll gate an error.

Please check why schema ignores a wrong case by viewId.

P.S. BTW, if viewID appears more then 1 time in JSON, then no warning, but if viewID appears only once, then IDE returns an error and proposes viewId instead and only if "flexEnabled": true. In a case "flexEnabled": false, there is no any error for viewID even if it appears only once in the targets section of a JSON.

@petermuessig
Copy link

Hi @pubmikeb ,

I can confirm, that when using the flexEnabled=false the issue with the viewID isn't recognized as this property is no required property anymore and we allow additionalProperties for the targets. We made a brief check what happens if we disallow additional properties but then a lot of manifests will break.

Do you have a suggestion how to overcome this? So that we can only validate the proper case-form of the viewId property?

Thanks and best regards,
Peter

@pubmikeb
Copy link
Author

pubmikeb commented Sep 2, 2020

Hi @petermuessig,

I'm not familiar so much with JSON schemas, so I don't know what could be done in such scenario.
Perhaps, within the schema there can be some or condition, which will allow several logical wing for schema validation. Just like JSDoc allows specifying a possible types of returning object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants