-
Notifications
You must be signed in to change notification settings - Fork 302
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
refactor(core): Homogenize all providers as static #671
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
I didn't test it though, so if we want this merged before the release, you might want to make sure all the affected examples are still working ok.
if (typeof (provider.preprocessDataLayer) !== 'function') { | ||
throw new Error(`Can't add provider for ${protocol}: missing a preprocessDataLayer function.`); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! That's the first step to really allow people to add their own providers (I mean, it was already possible, but you needed to know the internals of iTowns). Second step would be to document it :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you have in mind for documentation ? Something like iTowns/itowns.github.io#15 ? I can't see where else we could add it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe if we document the Scheduler
in fact
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using http://usejsdoc.org/tags-interface.html#virtual-comments in the Scheduler makes sense.
But maybe you should finish your refactoring commits before adding documentation...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will do in another PR.
Could you remove the unused providers as well ( |
cda22fb
to
758b193
Compare
You may want to add a |
73f1aac
to
60dc370
Compare
There is no reason to keep an instance of each provider, and moving them to static like some other one (PointCloudProvider for example) do no harm, but homogenize all providers to one structure. Also note that there are two required functions in a provider: preprocessDataLayer and executeCommand, that are verified when adding a provider, in the scheduler. BREAKING CHANGE: KML_Provider and BuildingBox_Provider have been removed, as well as getPointOrder from WFS_Provider.
60dc370
to
17c2546
Compare
Description
There is no reason to keep an instance of each provider, and moving them
to static like some other one (PointCloudProvider for example) do no
harm, but homogenize all providers to one structure.
Note that the function
getPointOrder
in the WFS provider is unused, should I delete it in this PR, or the associated TODO will be done by someone soon ?Also note that there are two required functions in a provider:
preprocessDataLayer and executeCommand, that are verified when adding a
provider, in the scheduler.
Motivation and Context
This comes in the work of #182, part of rewriting the Providers/Loader/etc system.