docs(spelling): Add codespell config + github action, run and fix a good number of typos (#3645)
This commit is contained in:
Yaroslav Halchenko authored and GitHub committed
1 parent
64079e0720
commit
11ca5b6eae
76 files changed
+128
-100
No files matched your search
@@ -18,7 +18,7 @@ Key features:
|
||||
Offers a Data Source API for communicating with archives over proprietary API
|
||||
formats.
|
||||
- Provides a plugin framework for creating task-based workflow modes which can
|
||||
re-use core functionality.
|
||||
reuse core functionality.
|
||||
- Beautiful user interface (UI) designed with extensibility in mind. UI
|
||||
components available in a reusable component library built with React.js and
|
||||
Tailwind CSS
|
||||
|
||||
@@ -117,7 +117,7 @@ Here are a list of some options available:
|
||||
decoding. Defaults to minimum of `navigator.hardwareConcurrency` and
|
||||
what is specified by `maxNumberOfWebWorkers`. Some windows machines require smaller values.
|
||||
- `acceptHeader` : accept header to request specific dicom transfer syntax ex : [ 'multipart/related; type=image/jls; q=1', 'multipart/related; type=application/octet-stream; q=0.1' ]
|
||||
- `requestTransferSyntaxUID` : Request a specific Tansfer syntax from dicom web server ex: 1.2.840.10008.1.2.4.80 (applyed only if acceptHeader is not set)
|
||||
- `requestTransferSyntaxUID` : Request a specific Tansfer syntax from dicom web server ex: 1.2.840.10008.1.2.4.80 (applied only if acceptHeader is not set)
|
||||
- `omitQuotationForMultipartRequest`: Some servers (e.g., .NET) require the `multipart/related` request to be sent without quotation marks. Defaults to `false`. If your server doesn't require this, then setting this flag to `true` might improve performance (by removing the need for preflight requests). Also note that
|
||||
if auth headers are used, a preflight request is required.
|
||||
- `maxNumRequests`: The maximum number of requests to allow in parallel. It is an object with keys of `interaction`, `thumbnail`, and `prefetch`. You can specify a specific number for each type.
|
||||
@@ -178,7 +178,7 @@ if auth headers are used, a preflight request is required.
|
||||
- `dangerouslyUseDynamicConfig`: Dynamic config allows user to pass `configUrl` query string. This allows to load config without recompiling application. If the `configUrl` query string is passed, the worklist and modes will load from the referenced json rather than the default .env config. If there is no `configUrl` path provided, the default behaviour is used and there should not be any deviation from current user experience.<br/>
|
||||
Points to consider while using `dangerouslyUseDynamicConfig`:<br/>
|
||||
- User have to enable this feature by setting `dangerouslyUseDynamicConfig.enabled:true`. By default it is `false`.
|
||||
- Regex helps to avoid easy exploit. Dafault is `/.*/`. Setup your own regex to choose a specific source of configuration only.
|
||||
- Regex helps to avoid easy exploit. Default is `/.*/`. Setup your own regex to choose a specific source of configuration only.
|
||||
- System administrators can return `cross-origin: same-origin` with OHIF files to disallow any loading from other origin. It will block read access to resources loaded from a different origin to avoid potential attack vector.
|
||||
- Example config:
|
||||
```js
|
||||
|
||||
@@ -109,7 +109,7 @@ You can open more than one study in the Viewer by adding the `StudyInstanceUIDs`
|
||||
|
||||
:::tip
|
||||
|
||||
You can ues this feature to open a current and prior study in the Viewer.
|
||||
You can use this feature to open a current and prior study in the Viewer.
|
||||
Read more in the [Hanging Protocol Module](../platform/extensions/modules/hpModule.md#matching-on-prior-study-with-uid) section. You can also use commas to separate
|
||||
values.
|
||||
|
||||
|
||||
@@ -239,7 +239,7 @@ To create a self-signed certificate:
|
||||
|Country Name (2 letter code) [AU]|
|
||||
|State or Province Name (full name) [Some-State]|
|
||||
|Locality Name (eg, city) []|
|
||||
|Organization Name (eg, company) [Internet Widgits Pty Ltd]|
|
||||
|Organization Name (eg, company) [Internet Widgets Pty Ltd]|
|
||||
|Organizational Unit Name (eg, section) []|
|
||||
|Common Name (e.g. server FQDN or YOUR name) []|
|
||||
|Email Address []|
|
||||
|
||||
@@ -93,7 +93,7 @@ support it yet, but it is gaining wider adoption.
|
||||
|
||||
If you have an existing archive and intend to host the OHIF Viewer at the same
|
||||
domain name as your archive, then connecting the two is as simple as following
|
||||
the steps layed out in our
|
||||
the steps laid out in our
|
||||
[Configuration Essentials Guide](./../configuration/configurationFiles.md).
|
||||
|
||||
#### What if I don't have an imaging archive?
|
||||
@@ -297,7 +297,7 @@ You can find an example of this setup in our
|
||||
|
||||
In general, we recommend using the "Authorization Code Flow" ( [see
|
||||
`response_type=code` here][code-flows]); however, the "Implicit Flow" ( [see
|
||||
`response_type=token` here][code-flows]) can work if additonal precautions are
|
||||
`response_type=token` here][code-flows]) can work if additional precautions are
|
||||
taken. If the flow you've chosen produces a JWT Token, it's validity can be used
|
||||
to secure access to your Image Archive as well.
|
||||
|
||||
|
||||
File renamed without changes.
@@ -101,7 +101,7 @@ quality and test coverage must not be changed by a significant margin. For some
|
||||
repositories, visual screenshot-based tests are also included, and video
|
||||
recordings of end-to-end tests are stored for later review.
|
||||
|
||||
[You can read more about our continous integration efforts here](/development/continous-integration.md)
|
||||
[You can read more about our continuous integration efforts here](/development/continuous-integration.md)
|
||||
|
||||
## Releases
|
||||
|
||||
|
||||
@@ -935,7 +935,7 @@ We have gone through extensive re-design of each part of the UI, and we have als
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
I have a huge complex styles using native CSS, how can I re-use them?
|
||||
I have a huge complex styles using native CSS, how can I reuse them?
|
||||
</summary>
|
||||
You can leverage the power of Tailwind CSS (https://TailwindCSS.com/) in OHIF v3 to reuse your existing styles. Tailwind CSS is a utility-first approach, allowing you to create reusable CSS classes by composing utility classes together. You can migrate your existing styles to Tailwind CSS by breaking them down into utility classes and utilizing the extensive set of predefined utilities provided by Tailwind CSS.
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ export default {
|
||||
*/
|
||||
id,
|
||||
|
||||
// Lifecyle
|
||||
// Lifecycle
|
||||
preRegistration() { /* */ },
|
||||
onModeEnter() { /* */ },
|
||||
onModeExit() { /* */ },
|
||||
@@ -182,7 +182,7 @@ Use the provided `cli` to add/remove/install/uninstall extensions. Read more [he
|
||||
|
||||
The final registration and import of the extensions happen inside a non-tracked file `pluginImport.js` (this file is also for internal use only).
|
||||
|
||||
After an extension gets registered withing the `viewer`,
|
||||
After an extension gets registered within the `viewer`,
|
||||
each [module](#modules) defined by the extension becomes available to the modes
|
||||
via the `ExtensionManager` by requesting it via its id.
|
||||
[Read more about Extension Manager](#extension-manager)
|
||||
@@ -206,7 +206,7 @@ used to initialize data.
|
||||
|
||||
[`onModeExit`](./lifecycle#onModeExit): Similarly to onModeEnter, this hook is
|
||||
called when navigating away from a mode, or before a mode’s data or datasource
|
||||
is changed. This can be used to cache data for re-use later, but since it
|
||||
is changed. This can be used to cache data for reuse later, but since it
|
||||
isn't known which mode will be entered next, the state after exiting should be
|
||||
clean, that is, the same as the state on a clean start. This is called BEFORE
|
||||
service clean up, and after mode specific onModeExit handling.
|
||||
|
||||
@@ -120,7 +120,7 @@ function ViewerLayout({
|
||||
commandsManager={commandsManager}
|
||||
/>
|
||||
|
||||
{/* Rigth SIDEPANELS */}
|
||||
{/* Right SIDEPANELS */}
|
||||
<SidePanel
|
||||
side="right"
|
||||
defaultComponentOpen={rightPanelComponents[0].name}
|
||||
|
||||
@@ -182,7 +182,7 @@ the following file tree:
|
||||
index.js
|
||||
| UK
|
||||
|-- Buttons.js
|
||||
indes.js
|
||||
index.js
|
||||
| US
|
||||
|-- Buttons.js
|
||||
index.js
|
||||
@@ -347,7 +347,7 @@ https://viewer.ohif.org/viewer/1.2.840.113619.2.5.1762583153.215519.978957063.78
|
||||
Chinese:
|
||||
https://viewer.ohif.org/viewer/1.2.840.113619.2.5.1762583153.215519.978957063.78?lng=zh
|
||||
|
||||
Portugese:
|
||||
Portuguese:
|
||||
https://viewer.ohif.org/viewer/1.2.840.113619.2.5.1762583153.215519.978957063.78?lng=pt-BR
|
||||
|
||||
Here are some links you can use to sign up to help translate. All you have to do
|
||||
|
||||
@@ -191,7 +191,7 @@ export default mode;
|
||||
### Consuming Extensions
|
||||
|
||||
As mentioned in the [Extensions](../extensions/index.md) section, in `OHIF-v3`
|
||||
developers write their extensions to create re-usable functionalities that later
|
||||
developers write their extensions to create reusable functionalities that later
|
||||
can be used by `modes`. Now, it is time to describe how the registered
|
||||
extensions will get utilized for a workflow mode via its `id`.
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ export default function getHangingProtocolModule() {
|
||||
}
|
||||
```
|
||||
|
||||
Within the protocol itself, the structure is layed out as described in the HangingProtocol.ts
|
||||
Within the protocol itself, the structure is laid out as described in the HangingProtocol.ts
|
||||
type definition, starting with `Protocol`. See the type definition for more details.
|
||||
|
||||
## Events
|
||||
@@ -71,7 +71,7 @@ the stage activate. The status values are:
|
||||
|
||||
* enabled - meaning that the stage is fully applicable
|
||||
* passive - meaning that the stage can be applied, but might be missing details
|
||||
* disabled - meaning that the study has insuffient information for this stage
|
||||
* disabled - meaning that the study has insufficient information for this stage
|
||||
|
||||
The default values for no `stageActivation` are to assume that `enabled` has `minViewports` of 1,
|
||||
and `passive` has `minViewports=0`. That is, enable the stage if at least one
|
||||
@@ -118,7 +118,7 @@ stageActivation: {
|
||||
stable as to exactly what this returns, as internal details can change.
|
||||
|
||||
- `getState`: Returns the currently applied protocol ID, stage index and active study UID.
|
||||
This information is storable/useable as state information to be used elsewhere.
|
||||
This information is storable/usable as state information to be used elsewhere.
|
||||
|
||||
- `getDefaultProtocol`: Returns the default protocol to apply.
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ grid store state as a modal state.
|
||||
```
|
||||
|
||||
### getState
|
||||
The `getState` call returns an object containing all of the reigstered states,
|
||||
The `getState` call returns an object containing all of the registered states,
|
||||
by id. The values can be read directly, but should not be modified.
|
||||
|
||||
### reduce
|
||||
|
||||
@@ -43,7 +43,7 @@ automatically when the extension or mode is loaded.
|
||||
In the `value` of each customizations, you will define customization prototype(s).
|
||||
These customization prototype(s) can be considered like "Prototype" in Javascript.
|
||||
These can be used to extend the customization definitions from configurations.
|
||||
Default cutomizations will be often used to define all the customization prototypes,
|
||||
Default customizations will be often used to define all the customization prototypes,
|
||||
as they will be loaded automatically along with the defining extension or mode.
|
||||
|
||||
|
||||
@@ -178,7 +178,7 @@ onModeEnter() {
|
||||
customizationType: 'ohif.cornerstoneOverlay',
|
||||
// The cornerstoneOverlay definition requires an items list here.
|
||||
items: [
|
||||
// Custom definitions for hte context menu here.
|
||||
// Custom definitions for the context menu here.
|
||||
],
|
||||
};
|
||||
customizationService.addModeCustomizations(bottomRight);
|
||||
@@ -285,7 +285,7 @@ uses it's own internal class names.
|
||||
* Name: 'class:StudyBrowser'
|
||||
* Attributes:
|
||||
** `true` for the is active true text color
|
||||
** `false` fo rhte is active false text color.
|
||||
** `false` for the is active false text color.
|
||||
** Values are button colors, from the Button class, eg default, white, black
|
||||
|
||||
## customRoutes
|
||||
|
||||
@@ -84,10 +84,10 @@ Check out the complete press announcement [here](https://ohif.org/newsletters/20
|
||||
- New UI components have been built with Tailwind CSS
|
||||
- Addition of workflow modes
|
||||
- Often, medical imaging use cases involves lots of specific workflows that
|
||||
re-use functionalities. We have added the capability of workflow modes, that
|
||||
reuse functionalities. We have added the capability of workflow modes, that
|
||||
enable people to customize user interface and configure application for
|
||||
specific workflow.
|
||||
- The idea is to re-use the functionalities that extensions provide and create
|
||||
- The idea is to reuse the functionalities that extensions provide and create
|
||||
a workflow. Brain segmentation workflow is different from prostate
|
||||
segmentation in UI for sure; however, they share the segmentation tools that
|
||||
can be re-used.
|
||||
|
||||
@@ -21,7 +21,7 @@ Free, Open Source Tools for Research: MONAI and OHIF Viewer
|
||||
We participated in the 38th Project Week with three projects around OHIF. [[Website](https://projectweek.na-mic.org/PW38_2023_GranCanaria/)]
|
||||
|
||||
- PolySeg representations for OHIF Viewer ([link](https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/OHIF_PolySeg/))
|
||||
- Cross study sychronizer for OHIF Crosshair ([link](https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/OHIF_SyncCrosshair/))
|
||||
- Cross study synchronizer for OHIF Crosshair ([link](https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/OHIF_SyncCrosshair/))
|
||||
- DATSCAN Viewer implementation in OHIF ([link](https://projectweek.na-mic.org/PW38_2023_GranCanaria/Projects/OHIF_DATSCAN/))
|
||||
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ Complex issues specific to your organization/situation are still okay to post,
|
||||
but they're less likely to receive a response. Unfortunately, we have limited
|
||||
resources and must be judicious with how we allocate them. If you find yourself
|
||||
in this situation and in need of assistance, it may be in your best interest to
|
||||
persue paid support.
|
||||
pursue paid support.
|
||||
|
||||
If you need additional help, please [reach out to us](https://ohif.org/get-support) to get more information on
|
||||
how we can help you.
|
||||
|
||||
@@ -54,7 +54,7 @@ This package also stores Meteor components for the interactive lesion table used
|
||||
### User (*ohif-user*)
|
||||
|
||||
### Basic Viewer Components (*ohif-viewerbase*)
|
||||
This is the largest package in the repository. It holds a large number of re-usable Meteor components that are used to build both the OHIF Viewer and Lesion Tracker.
|
||||
This is the largest package in the repository. It holds a large number of reusable Meteor components that are used to build both the OHIF Viewer and Lesion Tracker.
|
||||
|
||||
### WADO Proxy (*ohif-wadoproxy*)
|
||||
Proxy for CORS
|
||||
@@ -5,4 +5,4 @@ At the time of project conception, Meteor was a simple way to begin using bleedi
|
||||
|
||||
## Do you have any plans to stop using Meteor?
|
||||
|
||||
We have considered migrating templates from Blaze (http://blazejs.org/) to React (https://reactjs.org/) or Vue (https://vuejs.org/), simply because these decouple the view layer from the remainder of the application. Blaze currently lacks [Stand-alone Support](http://blazejs.org/#Better-Stand-alone-Support) which means that our templates are not re-usable outside of a Meteor application. This is certainly a downside, but the resource cost to migrate every template is significant.
|
||||
We have considered migrating templates from Blaze (http://blazejs.org/) to React (https://reactjs.org/) or Vue (https://vuejs.org/), simply because these decouple the view layer from the remainder of the application. Blaze currently lacks [Stand-alone Support](http://blazejs.org/#Better-Stand-alone-Support) which means that our templates are not reusable outside of a Meteor application. This is certainly a downside, but the resource cost to migrate every template is significant.
|
||||
@@ -59,7 +59,7 @@ This diagram is a conceptual illustration of how the Viewer is architected.
|
||||
|
||||
1. (optional) `extensions` can be registered with `@ohif/core`'s
|
||||
`ExtensionManager`
|
||||
2. `@ohif/core` provides bussiness logic and a way for `@ohif/viewer` to access
|
||||
2. `@ohif/core` provides business logic and a way for `@ohif/viewer` to access
|
||||
registered extensions
|
||||
3. The `@ohif/viewer` composes and provides data to components from our
|
||||
component library (`@ohif/ui`)
|
||||
|
||||
@@ -99,7 +99,7 @@ support it yet, but it is gaining wider adoption.
|
||||
|
||||
If you have an existing archive and intend to host the OHIF Viewer at the same
|
||||
domain name as your archive, then connecting the two is as simple as following
|
||||
the steps layed out in our
|
||||
the steps laid out in our
|
||||
[Configuration Essentials Guide](./../configuring/index.md).
|
||||
|
||||
#### What if I don't have an imaging archive?
|
||||
@@ -273,7 +273,7 @@ You can find an example of this setup in our
|
||||
|
||||
In general, we recommend using the "Authorization Code Flow" ( [see
|
||||
`response_type=code` here][code-flows]); however, the "Implicit Flow" ( [see
|
||||
`response_type=token` here][code-flows]) can work if additonal precautions are
|
||||
`response_type=token` here][code-flows]) can work if additional precautions are
|
||||
taken. If the flow you've chosen produces a JWT Token, it's validity can be used
|
||||
to secure access to your Image Archive as well.
|
||||
|
||||
|
||||
+1
-1
@@ -75,7 +75,7 @@ directory. Our build process knows which configuration file to use based on the
|
||||
and registered extension's features, are configured using this file.
|
||||
|
||||
The easiest way to apply your own configuration is to modify the `default.js`
|
||||
file. For more advanced cofiguration options, check out our
|
||||
file. For more advanced configuration options, check out our
|
||||
[configuration essentials guide](/configuring/index.md).
|
||||
|
||||
## Next Steps
|
||||
|
||||
+3
-3
@@ -8,7 +8,7 @@ sidebar_position: 4
|
||||
|
||||
At a certain point, you may want others to have access to your instance of the
|
||||
OHIF Viewer and its medical imaging data. This post covers one of many potential
|
||||
setups that accomplish that. Please note, noticably absent is user account
|
||||
setups that accomplish that. Please note, noticeably absent is user account
|
||||
control.
|
||||
|
||||
Do not use this recipe to host sensitive medical data on the open web. Depending
|
||||
@@ -21,12 +21,12 @@ that builds on the lessons learned here.
|
||||
|
||||
Our two biggest hurdles when hosting our image archive and web client are:
|
||||
|
||||
- Risks related to exposing our PACS to the netowrk
|
||||
- Risks related to exposing our PACS to the network
|
||||
- Cross-Origin Resource Sharing (CORS) requests
|
||||
|
||||
### Handling Web Requests
|
||||
|
||||
We mittigate our first issue by allowing [Nginx][nginx] to handle incoming web
|
||||
We mitigate our first issue by allowing [Nginx][nginx] to handle incoming web
|
||||
requests. Nginx is open source software for web serving, reverse proxying,
|
||||
caching, and more. It's designed for maximum performance and stability --
|
||||
allowing us to more reliably serve content than Orthanc's built-in server can.
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ less product offerings.
|
||||
While not required, it can simplify things to host your Web Viewer alongside
|
||||
your image archive. Services with more robust product offerings, like
|
||||
`Google Cloud`, `Microsoft's Azure`, and `Amazon Web Services (AWS)`, are able
|
||||
to accomodate this setup.
|
||||
to accommodate this setup.
|
||||
|
||||
_Drag-n-drop_
|
||||
|
||||
|
||||
+1
-1
@@ -77,7 +77,7 @@ _Create Your First User_
|
||||
- Email Verified: `ON`
|
||||
- Click `Save`
|
||||
- Click the `Credentials` Tab
|
||||
- New Pasword: `test`
|
||||
- New Password: `test`
|
||||
- Password Confirmation: `test`
|
||||
- Temporary: `OFF`
|
||||
- Click: `Reset Password`
|
||||
|
||||
+3
-3
@@ -1,10 +1,10 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
title: Continous Integration
|
||||
title: Continuous Integration
|
||||
---
|
||||
# Continous Integration (CI)
|
||||
# Continuous Integration (CI)
|
||||
|
||||
This repository uses `CircleCI` and `Netlify` for continous integration.
|
||||
This repository uses `CircleCI` and `Netlify` for continuous integration.
|
||||
|
||||
## Deploy Previews
|
||||
|
||||
@@ -14,7 +14,7 @@ we make to the OHIF Viewer, then follow these steps:
|
||||
- [Fork][fork-a-repo] the [OHIF/Viewers][ohif-viewers-repo] repository
|
||||
- [Create a local clone][clone-a-repo] of your fork
|
||||
- `git clone https://github.com/YOUR-USERNAME/Viewers`
|
||||
- Add OHIF/Viewers as a [remote repository][add-remote-repo] labled `upstream`
|
||||
- Add OHIF/Viewers as a [remote repository][add-remote-repo] labeled `upstream`
|
||||
- Navigate to the cloned project's directory
|
||||
- `git remote add upstream https://github.com/OHIF/Viewers.git`
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ choice for asserting an element's border color.
|
||||
|
||||
Modern tooling gives us this "for free". It can catch invalid regular
|
||||
expressions, unused variables, and guarantee we're calling methods/functions
|
||||
with the expected paramater types.
|
||||
with the expected parameter types.
|
||||
|
||||
Example Tooling:
|
||||
|
||||
|
||||
@@ -56,7 +56,7 @@ export default {
|
||||
*/
|
||||
id: 'example-extension',
|
||||
|
||||
// Lifecyle
|
||||
// Lifecycle
|
||||
preRegistration() { /* */ },
|
||||
// Modules
|
||||
getCommandsModule() { /* */ },
|
||||
|
||||
@@ -65,7 +65,7 @@ myCommandName: {
|
||||
| Property | Type | Description |
|
||||
| --------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `commandFn` | func | The function to call when command is run. Receives `options` and `storeContexts`. |
|
||||
| `storeContexts` | string[] | (optional) Expected state objects to be passed in as props. Located using `getAppState` fn defined at `CommandsManager`'s instatiation. |
|
||||
| `storeContexts` | string[] | (optional) Expected state objects to be passed in as props. Located using `getAppState` fn defined at `CommandsManager`'s instantiation. |
|
||||
| `options` | object | (optional) Arguments to pass at the time of calling to the `commandFn` |
|
||||
| `context` | string[] or string | (optional) Overrides the `defaultContext`. Let's us know if command is currently "available" to be run. |
|
||||
|
||||
@@ -150,7 +150,7 @@ It is up to the consuming application to define what contexts are possible, and
|
||||
which ones are currently active. As extensions depend heavily on these, we will
|
||||
likely publish guidance around creating contexts, and ways to override extension
|
||||
defined contexts in the near future. If you would like to discuss potential
|
||||
changes to how contexts work, please don't hesistate to createa new GitHub
|
||||
changes to how contexts work, please don't hesitate to create new GitHub
|
||||
issue.
|
||||
|
||||
[Some additional information on Contexts can be found here.](./../index.md#contexts)
|
||||
@@ -64,7 +64,7 @@ The simplest definition has the following properties:
|
||||
| `label` | User/display friendly to show in UI | \* |
|
||||
| `icon` | A string name for an icon supported by the consuming application. | \* |
|
||||
| `type` | Used to determine the button's component and behavior | `"setToolActive"`, `"command"` |
|
||||
| `commandName` | (optional) The command to run when the button is used. | Any command registed by a `CommandModule` |
|
||||
| `commandName` | (optional) The command to run when the button is used. | Any command registered by a `CommandModule` |
|
||||
| `commandOptions` | (optional) Options to pass the target `commandName` | \* |
|
||||
| `context` | (optional) Overrides module's `defaultContext` | Array of string context names |
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ fixes, and target their minimum JS support whenever possible.
|
||||
An example of a polyfill is that you expect `Array.prototype.filter` to exist,
|
||||
but for some reason, the browser that's being used has not implemented that
|
||||
language feature yet. Our earlier transpilation will rectify _syntax_
|
||||
discrepencies, but unimplemented features require a "temporary" implementation.
|
||||
discrepancies, but unimplemented features require a "temporary" implementation.
|
||||
That's where polyfills step in.
|
||||
|
||||
You can utilize a service like [polyfill.io](https://polyfill.io/v3/) to
|
||||
|
||||
@@ -4,7 +4,7 @@ sidebar_position: 2
|
||||
# Scope of Project
|
||||
|
||||
The OHIF Viewer is a web based medical imaging viewer. This allows it to be used
|
||||
on almost any device, anywhere. The OHIF Viewer is what is commonly reffered to
|
||||
on almost any device, anywhere. The OHIF Viewer is what is commonly referred to
|
||||
as a ["Dumb Client"][simplicable]
|
||||
|
||||
> A dumb client is software that fully depends on a connection to a server or
|
||||
@@ -12,7 +12,7 @@ as a ["Dumb Client"][simplicable]
|
||||
> software offers nothing useful. - [simplicable.com][simplicable]
|
||||
|
||||
While the Viewer persists some data, it's scope is limited to caching things
|
||||
like user preferences and previous query paramaters. Because of this, the Viewer
|
||||
like user preferences and previous query parameters. Because of this, the Viewer
|
||||
has been built to be highly configurable to work with almost any web accessible
|
||||
data source.
|
||||
|
||||
@@ -56,7 +56,7 @@ the OHIF Viewer as a desktop application.
|
||||
_Does the OHIF Viewer work with the local filesystem?_
|
||||
|
||||
It is possible to accomplish this through extensions; however, for an user
|
||||
experience that accomodates a large number of studies, you would likely need to
|
||||
experience that accommodates a large number of studies, you would likely need to
|
||||
package the OHIF Viewer as an [Electron app][electron].
|
||||
|
||||
<!--
|
||||
|
||||
@@ -19,7 +19,7 @@ Complex issues specific to your organization/situation are still okay to post,
|
||||
but they're less likely to receive a response. Unfortunately, we have limited
|
||||
resources and must be judicious with how we allocate them. If you find yourself
|
||||
in this situation and in need of assistance, it may be in your best interest to
|
||||
persue paid support.
|
||||
pursue paid support.
|
||||
|
||||
## Commercial Support
|
||||
|
||||
|
||||
@@ -100,7 +100,7 @@ quality and test coverage must not changed by a significant margin. For some
|
||||
repositories, visual screenshot-based tests are also included, and video
|
||||
recordings of end-to-end tests are stored for later review.
|
||||
|
||||
[You can read more about our continous integration efforts here](/development/continous-integration.md)
|
||||
[You can read more about our continuous integration efforts here](/development/continuous-integration.md)
|
||||
|
||||
## Releases
|
||||
|
||||
|
||||
@@ -93,7 +93,7 @@ export default withTranslation('MyNameSpace')(MyComponent);
|
||||
|
||||
> Important: if you are using React outside the OHIF Viewer, check the
|
||||
> [I18nextProvider](#using-outside-of-ohif-viewer) section, `withTranslation`
|
||||
> HOC doesnt works without a I18nextProvider
|
||||
> HOC doesn't works without a I18nextProvider
|
||||
|
||||
#### Using Hooks
|
||||
|
||||
@@ -187,7 +187,7 @@ the following file tree:
|
||||
index.js
|
||||
| UK
|
||||
|-- Buttons.js
|
||||
indes.js
|
||||
index.js
|
||||
| US
|
||||
|-- Buttons.js
|
||||
index.js
|
||||
|
||||
Reference in new issue
Block a user