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

xsd files for XML validation not found #7

Open
wombling opened this issue Mar 11, 2014 · 27 comments

Comments

@wombling
Copy link

commented Mar 11, 2014

When building XML views for UI5 it is very helpful to have the xsd to validate, aid with build, yet I cannot find these in the openUI5 downloads.

Could these be added?

@akudev akudev added the enhancement label Mar 11, 2014
@sirion

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2014

Hi wombling,

thank you for your input.
I'm not sure we have those. I've seen XSDs for the XMLModel but never for Views.
I will ask our experts if we can provide them.

Could you provide more details on why (for what) you need them?

Best regards,
Jens

@wombling

This comment has been minimized.

Copy link
Author

commented Mar 12, 2014

@bartonhammond

This comment has been minimized.

Copy link

commented Mar 29, 2014

Hi Chris,

That link references a com.sap.ui5.commons_x.x.x.jar to extract the xsd. I have downloaded everything from OpenUI5 site and can not find any jars at all. Where do we find these referenced jars?

Thanks,

Barton

@bartonhammond

This comment has been minimized.

Copy link

commented Mar 29, 2014

Oh - When I installed the Eclipse plugin, the jars are located in the Java Resoures / Libraries / SAPUI5 Core libraries. Good to go now.

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2014

👍

Please add the .xsd files to the non-eclipse dist SDK. The schema files are needed for code-completion with IDEs like WebStorm. http://scn.sap.com/community/developer-center/front-end/blog/2014/09/22/configuring-jetbrains-webstorm-for-ui5-development.

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2015

@sirion @matz3, any progress on this? The files are definately in the ui5 sdk eclipse plugin. Shouldn't be too much effor to include them in the openui5 dist.

Best Regards Christian

@akudev

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2015

Sometimes things are less simple than they appear: these files are result of the old, complex internal SAPUI5 Maven build. To my knowledge there is currently no mechanism to produce them from the OpenUI5 grunt build.
Either this mechanism would need to be created, or the files would need to be taken from the SAPUI5 build result.

@jmoors

This comment has been minimized.

Copy link

commented Jan 19, 2015

I noticed that WebIDE has different mechanism for generating the autocomplete, is it possible to generate from the javascript files, as I can't find the .control files in the openui5.

If there is a reliable mechanism for generating the information, and happy to investigate creating a grunt task.

Regards,
Jason

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2015

@jmoors I had a look at what the WebIDE loads. Apparently there's a file whose uri ends with sap/watt/common/config-preload.js https://webide-sapwebide.dispatcher.neo.ondemand.com/resources/~9807738bc59b4472fd69fbecb366b3559f7c074d~/sap/watt/common/config-preload.js .

Looking into this file I found multiple AMD modules defined which contain the string 'xmlcodecompletion'. Even though the sources are minified I could decrypt the stuff a bit using Safari. So I could find out that this file also contains the metadata about all controls which is needed for completion. Eg. which aggregations a control has, of which type a property is etc. You can search for example for 'sap.m.Button' then one of the matches is the definition of this control type.

Would be interesting to look how this has been created. However I would not be too surprised if this is just generated from the XMLs instead of directly from the source code.

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2015

@akudev Could the logic of the sapui5 maven build task which creates the XML files maybe shared somewhere, so that we're able to reimplement it in JS using node?

@akudev

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2015

@geekflyer I can check that tomorrow.

AFAIK there is currently a mechanism that restores the *.control files from the JS files, so the old mechanisms for API doc generation etc. (including this xsd) do still work. This would mean it's a suboptimal two-step process, where a re-implementation could take some shortcuts and would be welcome, even though we cannot get rid of the old mechanism that is still used for internal libraries of other teams that have not yet switched to the grunt build.

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2015

Ok thanks, looking forward for more information 👍

@jmoors

This comment has been minimized.

Copy link

commented Jan 19, 2015

I downloaded the WebIDE trial local version and found the com.sap.webide.orionplugin_1.4.4.jar contains the javascript files for reading the schema. Unfortunately it still seems to be generated from the XSD files.

/webide/resources/sap/watt/common/plugin/xmlcodecompletion
/webide/resources/sap/watt/common/plugin/jscodecompletion

I did look at the JSDocs however it doesn't seem to have enough information, if the control files could be included I think it would be possible to generate.

Regards,
Jason

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2015

@jmoors
The jsdoc does indeed not contain enough information. However there seems to be a metadata object attached to each control which appears to contain enough information. So one would have to parse that one, probably using esprima or something:
https://github.com/SAP/openui5/blob/master/src/sap.m/src/sap/m/Button.js

@codeworrior

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2015

Several building blocks for the XSD generation are already available in the OpenUI5 repo:

  • all metadata that formerly was maintained in the *.control or *.type files now is part of the Javascript code ('metadata' property of the object literal given to "extend" calls)
  • there exists code in the sap.ui.demokit library that parses a Control.js or a library.js and creates kind of metadata for it. It doesn't have the exact same features as the Java (Maven plugin) code that runs in our internal build (as Andreas explained above), but it's close to it.

Missing pieces:

  • Our Maven build plugin had an overview about all controls in a currently processed library X and about all libraries that 'X' depends on. In the grunt build, we don't have that overview yet. For the XSD files, such global knowledge is needed to properly resolve inheritance as well as type references in aggregations/associations etc. In Maven, the library dependencies had been expressed in several places, the pom.xml (used during build), the .library file (modetamodel) and in in the library.js. The last two are available in OpenUI5. As the ModuleAnalyzer already parses library.js and as that file also contains a list of types/controls/elements, it might be useful to analyse the initLibrary call as well:
    sap.ui.getCore().initLibrary({
        name : "sap.ui.commons",
        version: "${version}",
        dependencies : ["sap.ui.core","sap.ui.layout"],
        types: [
            "sap.ui.commons.ButtonStyle",
            ...
        ],
        interfaces: [
            "sap.ui.commons.FormattedTextViewControl",
            ...
        ],
        controls: [
            "sap.ui.commons.Accordion",
            ...
        ],
        elements: [
            "sap.ui.commons.AccordionSection",
            ...
        ]
    });
  • The main transformation was done by an XSL template (operating on *.control files). I'll check if we simply can attach it here or how we can communicate its content. Nevertheless, the gap mentioned above needs to be closed, at least if we want to create similar (compatible) XSD files. From our POV this would be preferred as it would allow to use Maven-built XSDs together with grunt-built XSDs.
@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2015

@codeworrior Seems nobody wants to volunteer to work on the XSD build from ui5 sources yet. Would it still be possible to publish the .xsd files somewhere? Probably the openui5 site and the sap development tools would be a good place: https://tools.hana.ondemand.com/#sapui5. Ideally would be to have all .xsd's as a zip file or as invidually downloadable resources.

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2015

@codeworrior I just wrote a node script which extracts the .xsd s automatically from an eclipse update site which serves the ui5 eclipse plugin jars. Can we publish the extracted .xsd somewhere here or on the openui5 site? The node script also can extract them automatically again, when a new plugin version comes out - just takes ~1 minute.

@codeworrior

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2015

Sorry, I was on a sick leave and couldn't answer earlier to your last post.

I don't think that extracting the files from one of our eclipse update site is a good way, at least from a licensing point of view. AFAIK, none of the UI5 related update sites is available under an open source license, but only under some SAP license. Extracting files from such a site and publishing them in the context of an open source site would raise more questions than it answers - at least to me.

After thinking about it again, I came to the conclusion that we've ignored a much easier solution. When we internally build the OpenUI5 SDK for the OpenUI5 download section, we have the schemas already available. We just kick them out of the resulting webapp because of their file name and location (not part of the "META-INF/resources" folder of our jars). We just need to find a better location for them, but then it shouldn't be too much effort.

I most likely won't manage to do this before end of next week. But one of the next downloadable SDKs will contain the XSDs for the OpenUI5 libs!

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2015

👍 That sounds great. For the openui5 libs that should solve it.

I'm not sure whether this is the right adress here, but it would be great if the .xsds are also included in the sapui5 sdk download on SCN, which additionally covers the sap.ca, sap.suite namespace etc..

Best Regards Christian

@codeworrior

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2015

After we internally agree on a location for those files within the SDK, I think the same approach can be taken for the full SAPUI5 SDK.

@codeworrior

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2015

Yes, that's the location that we agreed on for now.

Future SDKs will contain the schema files for the delivered libraries in the download/schemas/ folder. The name of each file is the name of the library + ".xsd" extension.

For those that are working with SAPUI5 on any of the supported server platforms: the SAPUI5 SDK will also contain the schema files for all libraries that it delivers. Same location, same naming scheme.

I know, an index file for that folder would have been nice, but there's always room for improvement ;-)

@geekflyer

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2015

👍

@p0rsche

This comment has been minimized.

Copy link

commented Mar 19, 2015

Would be great if you'll also provide sap.ui.core.mvc.xsd and others, because it can be found in documentation samples.

@akudev

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2015

Hi Vladimir,
sap.ui.core.mvc is not a library on its own, but a sub-package within sap.ui.core, and as such it is described within
https://openui5beta.hana.ondemand.com/downloads/schemas/sap.ui.core.xsd

Regards
Andreas

@p0rsche

This comment has been minimized.

Copy link

commented Mar 19, 2015

But I'm still keep getting an errors even if I add sap.ui.core.mvc namespace to my IDE (Webstorm) (example from demo app - TDG)
view.xml
settings

@codeworrior

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2015

  1. Vladimir is right. The XSDs and the namespace concepts in the view don't really fit to each other. When the XSDs and their structure have been defined, it was planned to adapt the View to the same concept (one (proper) namespace per library, control and element tag names omit the subpackage, option to define a tag name different from the unqualified class name). But that step was never made and the Views established as they are with the non-full-URI namespaces etc.
  2. Andreas is also right. All content of sap.ui.core is described in sap.ui.core.xsd, including the subpackage sap.ui.core.mvc.

The only workaround that I'm aware of to close that gap is to temporarily map xmlns:mvc to "sap.ui.core" instead of "sap.ui.core.mvc". The validation wlll be happy then, but the runtime won't.

"Would be great" if we could split the XSDs in future :-)

@akudev akudev referenced this issue Mar 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.