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

Not all properties have completion suggestions provided by enum lists #5

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

Comments

@pubmikeb
Copy link

pubmikeb commented Jul 2, 2020

It would be great if all schema properties, which have a closed set of possible values would provide suggestions powered by enum, just like property _version does.

For instance, the following properties don't provide a code completion suggestions:

  • sap.app/i18n/supportedLocales
  • sap.app/i18n/fallbackLocale
  • sap.ui5/models/i18n/settings/supportedLocales
  • sap.ui5/models/i18n/settings/fallbackLocale
  • sap.ui5/dependencies/libs
  • sap.ui5/dependencies/minUI5Version
  • sap.ui5/models

That's the whole idea of a manifest JSON-schema — to assist a developer to choose a proper value from a closed set of possible ones. To save a time and not to go to an API documentation.

Ideally, every non-app-specific value should provide a suggestion.

@petermuessig
Copy link

Hi @pubmikeb ,

regarding the supportedLocalesand fallbackLocalewe do not have an enum in our code base. Even worse, in case of technical languages and text verticalization the language codes are not max. 5 chars long and can be even longer, e.g. en_US_saptrc or en_US_sappsd.

The same applies to our libs and to the minUI5version. This information should be ideally read and integrated via another reading the information e.g. from the SAPUI5 SDK on SAP CP since it is dependent on the version and the UI5 versions even increase independent from the manifest version.

For the models, especially the model types, we could foresee something like an enum but in addition we need to allow additional entries otherwise this would prevent the usage of custom models in the manifest.json.

Would you be ok with this?

THX and best regards,
Peter

@pubmikeb
Copy link
Author

pubmikeb commented Jul 3, 2020

Hi @petermuessig,

Even worse, in case of technical languages and text verticalization the language codes are not max. 5 chars long and can be even longer, e.g. en_US_saptrc or en_US_sappsd.

I though, that both supportedLocales and fallbackLocale are both supposed to contain the language codes in ISO 639-1 only.

This information should be ideally read and integrated via another reading the information e.g. from the SAPUI5 SDK on SAP CP since it is dependent on the version and the UI5 versions even increase independent from the manifest version.

That sounds complicated, perhaps a static generation of enums prior release of a new UI5 build for both: list of available libraries (libs) and list of available UI5 versions (minUI5version) could be sufficient to provide a code completion for end-developer?

For the models, especially the model types, we could foresee something like an enum but in addition we need to allow additional entries otherwise this would prevent the usage of custom models in the manifest.json.

That can be OK. The key idea, I want to get a suggestions from the IDE what to write, at least for the default, not custom models.
Currently I have the following models code:

"models": {
	"i18n": {
		"settings": {
			"bundleName": "webapp.i18n.i18n",
			"bundleUrl": "i18n/i18n.properties",
			"fallbackLocale": "en",
			"supportedLocales": [
				"en",
				"de"
			]
		},
		"type": "sap.ui.model.resource.ResourceModel"
	}
},

But IDE doesn't provide any assistance for models.

@petermuessig
Copy link

Hi @pubmikeb ,

we will investigate the option a bit more in depth to have recommendations by the IDE but in addition allow also free text entries.

Regarding the language codes, we follow the BCP-47 syntax since we also need to have proper support for regions and not only for languages. In addition, for technical languages like pseudo translations we use the possibility to add additional variants. The ISO 639-1 is just the language code in the beginning.

For the libs and minUI5Version we also may think about something like this - but as the manifests' lifecycle is independent from the UI5 lifecycle it might be a bit complicated with the static generation. Also some space for research I would suppose.

I will take these points to the dev team for research and keep you posted...

Best regards,
Peter

@pubmikeb
Copy link
Author

pubmikeb commented Sep 2, 2020

@petermuessig,

Thanks a lot for the detailed explanation!

Best regards,
Mike

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