Bugzilla – Full Text Bug Listing
| Summary: | [client] Review symbolic service names | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Simon Kaegi <simon_kaegi> |
| Component: | Client | Assignee: | John Arthorne <john.arthorne> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski, mamacdon, susan |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Simon Kaegi
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. |