mirror of
https://github.com/mermaid-js/mermaid.git
synced 2025-08-15 14:29:25 +02:00
spelling: cannot
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
This commit is contained in:
@@ -451,7 +451,7 @@ For public sites, it can be precarious to retrieve text from users on the intern
|
|||||||
|
|
||||||
As an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing javascript in the code from being executed. This is a great step forward for better security.
|
As an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing javascript in the code from being executed. This is a great step forward for better security.
|
||||||
|
|
||||||
_Unfortunately you can not have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._
|
_Unfortunately you cannot have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._
|
||||||
|
|
||||||
## Reporting vulnerabilities
|
## Reporting vulnerabilities
|
||||||
|
|
||||||
|
@@ -437,7 +437,7 @@ For public sites, it can be precarious to retrieve text from users on the intern
|
|||||||
|
|
||||||
As an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing JavaScript in the code from being executed. This is a great step forward for better security.
|
As an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing JavaScript in the code from being executed. This is a great step forward for better security.
|
||||||
|
|
||||||
_Unfortunately you can not have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._
|
_Unfortunately you cannot have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._
|
||||||
|
|
||||||
## Reporting vulnerabilities
|
## Reporting vulnerabilities
|
||||||
|
|
||||||
|
@@ -171,7 +171,7 @@ Cardinality is a property that describes how many elements of another entity can
|
|||||||
|
|
||||||
### Identification
|
### Identification
|
||||||
|
|
||||||
Relationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question can not have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : "driver"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line:
|
Relationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question cannot have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : "driver"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line:
|
||||||
|
|
||||||
| Value | Alias for |
|
| Value | Alias for |
|
||||||
| :---: | :---------------: |
|
| :---: | :---------------: |
|
||||||
|
@@ -278,7 +278,7 @@ stateDiagram-v2
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
_You can not define transitions between internal states belonging to different composite states_
|
_You cannot define transitions between internal states belonging to different composite states_
|
||||||
|
|
||||||
## Choice
|
## Choice
|
||||||
|
|
||||||
|
@@ -32,7 +32,7 @@ When rendering this diagram it is being rendered recursively. The diagram is ren
|
|||||||
|
|
||||||
_Data for a clusterNode_
|
_Data for a clusterNode_
|
||||||
|
|
||||||
When a cluster has edges to or from some of its nodes leading outside the cluster the approach of recursive rendering can not be used as the layout of the graph needs to take responsibility for nodes outside of the cluster.
|
When a cluster has edges to or from some of its nodes leading outside the cluster the approach of recursive rendering cannot be used as the layout of the graph needs to take responsibility for nodes outside of the cluster.
|
||||||
|
|
||||||
```mermaid
|
```mermaid
|
||||||
flowchart
|
flowchart
|
||||||
|
@@ -40,7 +40,7 @@ describe('when parsing ER diagram it...', function () {
|
|||||||
allowed.forEach((allowedChar) => {
|
allowed.forEach((allowedChar) => {
|
||||||
const singleOccurrence = `Blo${allowedChar}rf`;
|
const singleOccurrence = `Blo${allowedChar}rf`;
|
||||||
const repeatedOccurrence = `Blo${allowedChar}${allowedChar}rf`;
|
const repeatedOccurrence = `Blo${allowedChar}${allowedChar}rf`;
|
||||||
const cannontStartWith = `${allowedChar}Blorf`;
|
const cannotStartWith = `${allowedChar}Blorf`;
|
||||||
const endsWith = `Blorf${allowedChar}`;
|
const endsWith = `Blorf${allowedChar}`;
|
||||||
|
|
||||||
it(`${singleOccurrence} fails if not surrounded by quotes`, function () {
|
it(`${singleOccurrence} fails if not surrounded by quotes`, function () {
|
||||||
@@ -73,7 +73,7 @@ describe('when parsing ER diagram it...', function () {
|
|||||||
expect(entities.has(name)).toBe(true);
|
expect(entities.has(name)).toBe(true);
|
||||||
});
|
});
|
||||||
|
|
||||||
it(`"${cannontStartWith}" cannot start with the character`, function () {
|
it(`"${cannotStartWith}" cannot start with the character`, function () {
|
||||||
const name = repeatedOccurrence;
|
const name = repeatedOccurrence;
|
||||||
expect(() => {
|
expect(() => {
|
||||||
erDiagram.parser.parse(`erDiagram\n "${name}"\n`);
|
erDiagram.parser.parse(`erDiagram\n "${name}"\n`);
|
||||||
|
@@ -192,7 +192,7 @@ For public sites, it can be precarious to retrieve text from users on the intern
|
|||||||
|
|
||||||
As an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing JavaScript in the code from being executed. This is a great step forward for better security.
|
As an extra level of security for sites with external users we are happy to introduce a new security level in which the diagram is rendered in a sandboxed iframe preventing JavaScript in the code from being executed. This is a great step forward for better security.
|
||||||
|
|
||||||
_Unfortunately you can not have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._
|
_Unfortunately you cannot have a cake and eat it at the same time which in this case means that some of the interactive functionality gets blocked along with the possible malicious code._
|
||||||
|
|
||||||
## Reporting vulnerabilities
|
## Reporting vulnerabilities
|
||||||
|
|
||||||
|
@@ -125,7 +125,7 @@ Cardinality is a property that describes how many elements of another entity can
|
|||||||
|
|
||||||
### Identification
|
### Identification
|
||||||
|
|
||||||
Relationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question can not have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : "driver"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line:
|
Relationships may be classified as either _identifying_ or _non-identifying_ and these are rendered with either solid or dashed lines respectively. This is relevant when one of the entities in question cannot have independent existence without the other. For example a firm that insures people to drive cars might need to store data on `NAMED-DRIVER`s. In modelling this we might start out by observing that a `CAR` can be driven by many `PERSON` instances, and a `PERSON` can drive many `CAR`s - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: `PERSON }|..|{ CAR : "driver"`. Note the two dots in the middle of the relationship that will result in a dashed line being drawn between the two entities. But when this many-to-many relationship is resolved into two one-to-many relationships, we observe that a `NAMED-DRIVER` cannot exist without both a `PERSON` and a `CAR` - the relationships become identifying and would be specified using hyphens, which translate to a solid line:
|
||||||
|
|
||||||
| Value | Alias for |
|
| Value | Alias for |
|
||||||
| :---: | :---------------: |
|
| :---: | :---------------: |
|
||||||
|
@@ -160,7 +160,7 @@ stateDiagram-v2
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
_You can not define transitions between internal states belonging to different composite states_
|
_You cannot define transitions between internal states belonging to different composite states_
|
||||||
|
|
||||||
## Choice
|
## Choice
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user