PlatformApi definition and documentation. #9
Conversation
|
As and addition to this proposal, to make exception handling more accurate in high-level API, we may want to have a number of different error classes, or introduce an |
|
@purplecabbage, @stevengill, Please take a look in a spare time. |
|
This looks great! Awesome job Vladimir. Do you plan to integrate https://github.com/apache/cordova-lib/tree/master/cordova-lib/src/cordova/metadata and https://github.com/apache/cordova-lib/tree/master/cordova-lib/src/plugman/platforms replacements into this. Would some of these files go into Thoughts on having a I will have to play around with it more as we implement it. I'm definitely down to help with this as I have wanted cordova to work better with non cli node projects for a while. Not sure if this is relevant to this discussion, but I noticed plugin dependencies get handled a layer above this. So |
|
Thanks, Steve.
Yes, the logic from
Definitely will add it. Regarding managing dependencies - if we decide to do this in platform, we'll need to make platform responsible for fetching plugins - thing I would like to avoid. It might make sense to factor dependecy resolver into |
- Adds updatePlatform static method, - Makes getPlatformInfo method non-static, - Updates removePlugin method to accept PluginInfo instance as input parameter instead of plugin id.
|
Updated PlatformApi slightly according to notes on this PR and added description for CordovaProject class which abstracts project-related information. |
| /** | ||
| * Gets a PlatformInfo object, that represents the platform structure. | ||
| * | ||
| * @return {PlatformInfo} A structure that contains the description of |
There was a problem hiding this comment.
Where is the definition for PlatformInfo? Should this be called CordovaPlatform or PlatformApi be called CordovaPlatform to make the naming consistent with CordovaProject
There was a problem hiding this comment.
Added definition in 4992734 and updated the name. However, we might need an additional discussion on naming classes.
|
Closing this in favor of #12 |
| * | ||
| * @type {String} | ||
| */ | ||
| cordovaJs: path.join('bin', 'template', 'www', 'cordova.js'), |
There was a problem hiding this comment.
Should we be exposing this file ? I think we should expose the one that gets generated by 'prepare' and is in the 'www' folder.
|
Can't remember exactly, but this looks like the part of compatibility stuff. The cordova-js source path is required somewhere inside cordova-lib. But in general, yes, you're right, this is not really required to be exposed. |
This proposal describes a high-level classes which describes Cordova project and Cordova platform as a strictly typed APIs:
The aim of this document is to discuss and finalize API details and provide a reference for implementing ProjectApi and PlatformApi for new platforms or updating the old ones to new model.
To make the transition to new API smoother, the cordova-lib needs to be updated to expose the same class, which will work as a polyfill in case if platform doesn't provides its own PlatformApi.
There also a potential problem of code duplication, since the PlatformApi needs for several classes, which currently being stored and exposed by cordova-lib: ConfigParser, PluginInfo, etc. The one of solutions of this problem - is to factor out the common classes and routines to shared module (proposed name -
cordova-common), which then will be released separately. This approach is discussed in cordova-lib/#235.The transition steps might be the following:
cordova-commonmodule and publish it separately.Still in progress:
ProjectInfo/PlatformInfoclassesMore links: