Community
Participate
Working Groups
At the moment we have a mixture of "I" names and simple names for our services. This is not going to cut it in the long haul and we should review the names at some point soon-ish.
I would prefer us using simple names, not something that starts with the letter "I".
By "simple names" are we ruling out some kind of hierarchical naming convention for services?
I think it has to be hierarchical. Otherwise as Orion itself and the ecosystem grows it would become unmanageable. Something like: orion.core.* for basic Eclipse Application Services orion.git.* for git services orion.sites.* for site management services orion.editor.* for editor related services
Here are the current service names that I could find: This first set of services are effectively "extension points". The caller will process all available implementations to somehow customize/augment the page behaviour: editorAction IFileService IContentAssistService ISyntaxHighlight fileCommands openWith primaryNavigation landingTasks These are currently treated as singleton services. Callers assume there can only be one in a given system. Some of these are really extension points but we assume a single extension: testRunner IGitService IProblemProvider Selection ICommandService IPreferenceService IFavorites IDialogService IStatusReporter ISshService IUsersService IOutlineProvider IEditorSyntaxChecker We recently talked about a two-level convention for everything (orion.someService). However after reviewing how many names we already have, I really like the idea of being able to group together related services and avoid a single "melting pot" of services.I think in the long term two-level names would break down and become confusing for consumers ("which of these 300 services involves customizing the editor??"). Anyway, there is an initial suggestion: All services are three levels: orion.category.someService. If a service is mostly used on a specific page, then the "category" would be the name of the page. There are a couple of extra categories for cross-cutting services. I have avoided junk terms like "service", "provider", etc. I have made all names singular to avoid falling into the trap of assuming some services as defacto-singletons while others potentially have multiple implementations. Services that have no specific relation to user interface elements: IFileService -> orion.core.file IPreferenceService -> orion.core.preference IUsersService -> orion.core.user IProblemProvider -> orion.core.marker Services related to editing and the editor: editorAction -> orion.edit.command IContentAssistService -> orion.edit.contentAssist ISyntaxHighlight -> orion.edit.highlighter IOutlineProvider -> orion.edit.outline IEditorSyntaxChecker -> orion.edit.validator Services related to navigation and the navigate page: fileCommands -> orion.navigate.command openWith -> orion.navigate.openWith landingTasks -> orion.navigate.landingTask IFavorites -> orion.navigate.favorite primaryNavigation -> orion.navigate.link General "ui" services that would be used by any page: Selection -> orion.page.selection ICommandService -> orion.page.command IDialogService -> orion.page.dialog IStatusReporter -> orion.page.message Miscellaneous: testRunner -> orion.test.runner IGitService -> orion.git.provider ISshService -> orion.team.ssh
Excellent. Thanks, John. I like it!
Yep agree. These look good -- even the camelCase. Go for it.
Great! I like it, but... I don't see the general issue of "navigating through Orion" as being related to the thing we call the "navigator page." I'd like the orion.navigate.* namespace to be similar to orion.edit.* namespace, more page-specific. In my mind, the general issue of navigation is really more general (orion.core.*, orion.page.*) and the stuff for the file navigator should be grouped separately. That would mean: primaryNavigation -> orion.page.link IFavorites -> orion.core.favorite (the favorites service is really just a specialized form of preferences and doesn't have a UI. We also have a favorites UI component but that is not what IFavorites refers to) landingTasks -> orion.welcome.tasks (the landing page isn't really just a navigation thing. It feels "misc" to me, and I could see us extending it in other ways. Using "welcome" since we've used that in eclipse)
Thanks for the feedback Susan. I tried at first to make it consistently orion.<page>.<service>, but ran into trouble when I hit several services that cut across all pages (primaryNavigation, favorites, etc). Your revisions make sense. Instead of orion.welcome.task I have changed it to orion.help.task. I can see "help" having a cluster of related services once we get into context-sensitive help, cheat sheets, etc. So the new list is: Services that have no specific relation to user interface elements: IFileService -> orion.core.file IPreferenceService -> orion.core.preference IUsersService -> orion.core.user IProblemProvider -> orion.core.marker IFavorites -> orion.core.favorite Services related to editing and the editor: editorAction -> orion.edit.command IContentAssistService -> orion.edit.contentAssist ISyntaxHighlight -> orion.edit.highlighter IOutlineProvider -> orion.edit.outline IEditorSyntaxChecker -> orion.edit.validator Services related to the navigate page: fileCommands -> orion.navigate.command openWith -> orion.navigate.openWith General "ui" services that would be used by any page: Selection -> orion.page.selection ICommandService -> orion.page.command IDialogService -> orion.page.dialog IStatusReporter -> orion.page.message primaryNavigation -> orion.page.link Miscellaneous: testRunner -> orion.test.runner IGitService -> orion.git.provider ISshService -> orion.team.ssh landingTasks -> orion.help.task
(In reply to comment #8) > So the new list is: +1
Small update: After reviewing the code, orion.team.ssh didn't feel right. There is nothing inherently "team" about doing SSH communication. I changed this to: ISshService -> orion.net.ssh
I have pushed all the renaming changes. I am leaving this open for now until the list of services is documented somewhere.
(In reply to comment #11) > I have pushed all the renaming changes. I am leaving this open for now until > the list of services is documented somewhere. Are you sure you pushed this? I don't see the changes. Here's my guess: - you had to go to Eclipse to do the global search/replace - so you changed some local git repo - maybe not the one you pushed from Orion?
(In reply to comment #12) > Are you sure you pushed this? I don't see the changes. You're right, this didn't get pushed. I can't figure out what happened. I staged it in several commits because I was worried about breaking things. Here are some commit refs: http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/commit/bundles?id=6ea636f05b7f3d20f493c7a092d886dc2b2ff088 http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/commit/bundles?id=2c9bf5f0c7edf1f2623a540b93d4d0c82eb4eb1c http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/commit/bundles?id=2cf5f62d14fa03f6297cae8f2d929368cb495ef9 http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/commit/bundles?id=f4677d37bfd247e182786dce05544ded47268a59 http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/commit/bundles?id=1c20a187d8007dcb6cd4107fa1658babb1a144d7
By the way, renaming the service called "Selection" was a massive pain - there were hundreds of search results. I've done some basic testing but still fear I could have broken something. Most of the others were relatively easy search/replace.
All good now. Thanks John.
I'll make sure to touch the selection scenarios today.
This was done.
