merge w master

This commit is contained in:
akcodez
2023-06-05 10:56:19 -07:00
23 changed files with 620 additions and 37 deletions

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

View File

@@ -1,3 +1,3 @@
CLIENT="wss://s.altnet.rippletest.net/" CLIENT="wss://s.altnet.rippletest.net:51233/"
EXPLORER_NETWORK="testnet" EXPLORER_NETWORK="testnet"
SEED="s████████████████████████████" SEED="s████████████████████████████"

View File

@@ -0,0 +1,82 @@
---
html: contribute-code-flow.html
parent: amendments.html
blurb:
labels:
- Blockchain
---
# Contribute Code to the XRP Ledger
The software that powers the XRP Ledger is open source. Anyone can download, modify, extend, or explore it. If you want to contribute code, it's important to work with the community to define the specifications of your changes and test the code before adding it to `rippled`.
## XRP Ledger Standards
Changes to `rippled` are tracked by an XRP Ledger Standard (XLS), a document that identifies and details the specifications of a change. Before committing to development, you must start a discussion in the [XRPL-Standards repo](https://github.com/XRPLF/XRPL-Standards/discussions). This provides the community a chance to discuss and provide feedback about your change.
**Note:** Bug fixes don't require an XLS, but may require an amendment.
Creating an XLS has its own process, but can be summarized as:
1. Start a discussion and gather feedback.
2. Create an XLS draft in the standards repo.
3. Publishing the XLS draft as a Candidate Specification.
For details, see the [XLS contributing guide](https://github.com/XRPLF/XRPL-Standards/blob/master/CONTRIBUTING.md).
## Amendment Implementation
After you've created an XLSd, you now need to determine if your change requires an amendment. Changes that affect **transaction processing** require amendments, specifically changes that:
- Modify ledger rules, resulting in different outcomes.
- Add or remove transactions.
- Affect consensus.
**Note:** If your change doesn't need an amendment, you can go straight to coding and deployment.
Implementing code as an amendment requires you to add the amendment to these files:
- **Feature.cpp**:
`Supported` parameter should be set to `no` until development is complete.
`DefaultVote` parameter should be set to `yes` for bug fixes; everything else defaults to `no`.
- **Feature.h**: Increment the `numFeatures` counter and declare an `extern uint256 const` variable.
## Coding and Deployment
The general development path breaks down as follows:
1. Create a fork or branch in the [`rippled` repository](https://github.com/XRPLF/rippled) to develop your code.
**Tip:** If you're not sure where to start, _Dev Null Productions_ provides a detailed and thorough [`rippled` Source Code Guide](https://xrpintel.com/source).
2. Run unit and integration tests. Running a server in _stand-alone mode_ is useful for testing your changes in an isolated environment, but you may want to stand up a private network for extensive changes.
3. Create a pull request on `XRPLF:develop`.
**Note for Amendments:** Update the `Supported` paramter to `yes` in **Feature.cpp**.
4. After the pull request is approved by XRP Ledger maintainers, your code is merged into `develop` and additional testing can be done on Devnet.
**Note for Amendments:**
- The `DefaultVote` parameter is now locked.
- If problems are found with the amendment, you must restart the process of making fixes and submitting a new PR. You can change the default vote in the new PR.
5. On a quarterly basis, a release candidate is built from approved PRs on `develop`. The package is deployed to Testnet and a few nodes on Mainnet. If no issues are found with the release candidate, the code is merged into `master` and nodes on Mainnet can upgrade to this build.
6. New amendments go through the consensus process and validators vote on whether to enable them.
## Code Flowchart
![Code Flowchart](img/Contribute Code Flowchart.png)
## See Also
- **Concepts:**
- [Amendments](amendments.html)

View File

@@ -0,0 +1,85 @@
---
html: tutorial-guidelines.html
parent: contribute.html
---
# Tutorial Guidelines
We are creating a modular tutorial framework that allows developers to learn how transactions and requests work on the XRP Ledger. Developers can review the modules to learn about business solutions, and potentially repurpose the scripts in their own applications.
# Rationale
What a developer wants comes down to two things:
1. Sample code snippets they can copy and paste into their own applications.
2. Complete API reference documentation.
Keep the conceptual information to a minimum only the information necessary to complete the tutorial. For background or deeper understanding, provide links to the conceptual topics at the end of the tutorial, if needed.
Modular tutorials follow Malcolm Knowles six assumptions for designing adult learning:
1. Adults need to know why they need to learn something.
2. Adults need to build on their experience.
3. Adults have a need to feel responsible for their learning.
4. Adults are ready to learn if training solves an immediate problem.
5. Adults want their training to be problem focused.
6. Adults learn best when motivation comes intrinsically.
Add into that Ralph Smedleys quote, “We learn best in moments of enjoyment.” Taking a lighter touch helps to relax the learner so that the material flows into their brain with less resistance.
# Sample Code vs. Tasks vs. Concepts vs. Tutorials
To date, there have been some blurred lines where different types of documentation show up as _Tutorials._ Here are some comparisons that help define the distinction.
## Sample Code
Sample code is well commented snippets or applications that illustrate best practices for implementing a feature of the API. Sample code is modular and reusable with little customization required.
Sample code is desirable, because advanced users can typically scan the example and use it immediately without a formal tutorial. It can also be used by others as a basis for tutorials. Sample code developers can focus on what they do well, while technical writers and support personnel can use the samples to create quality training materials.
## Tasks
Tasks are step-by-step instructions for how to accomplish a specific result. For example, “Installing rippled on a Red Hat Linux Server.” Task documentation is not intended to be particularly educational. It frequently describes tasks that are only performed one time per implementation, or maintenance tasks that always follow a familiar pattern. Tasks provide troubleshooting guidance, since there are likely variables that the user must adjust based on the specifics of their use case.
## Concepts
Conceptual information describes elements of the API, how they work, and when to use them. If a tutorial requires lengthy explanations before or during the programming tasks, consider how you might separate the exposition into a new topic, or link to existing topics that set the proper context.
For example, three paragraphs of context and a single line of code would be a concept, not a tutorial.
## Tutorials
Tutorials begin with sample code that illustrates best practices for implementing a feature. They take the developer step-by-step through the development process, explaining the purpose of each block of code.
Tutorials further combine a number of features to work together to solve a business problem. They describe the straightforward sunny day path to complete a task. Then, the tutorial might suggest modifications that let the developer try several different scenarios. Due to their focus on a certain limited scope of behavior, tutorials should not require extensive troubleshooting information.
## Use Cases
Use cases describe how to pull together multiple features to create a practical application that solves a business problem. They provide context and assistance with the decision making process, then provide links to the appropriate topics for each step of implementation.
# Tutorial Components
This section describes the elements of the modular tutorials used on XRPL.org.
## Sample Application
XRPL tutorial code samples are modular in nature. For example, Script 1 demonstrates how to create a test account, access the XRP Ledger, and transfer XRP between accounts. Any further samples can reuse the functions in Script 1.
Create a new script with the specific, minimal function code required to demonstrate the practical solution to a business problem. The examples should be incremental, with just enough behaviors to illustrate a business process.
For example, the first NFT tutorial shows how to mint, retrieve, and burn an NFT. The next tutorial shows how to create and accept a sell offer, and create and accept a buy offer.
Dont focus too much on the UX of the application, unless the look and feel is pertinent to the topic. Use the standard CSS file with the look and feel for all of the tutorials.
Reuse the code from other modules when possible. There might be situations where you need to modify the behavior from an earlier module. You can either overload the function name or modify the module and save it with a different name.

View File

@@ -0,0 +1,54 @@
---
html: tutorial-structure.html
parent: contribute.html
---
# Tutorial Structure
Each XRP Ledger tutorial follows the same format.
1. A brief description of the features illustrated in the tutorial.
2. Prerequisites for running the code, if needed, or links to the sample code.
3. Usage examples of the features in the tutorial.
4. A code walkthrough of the sample application, highlighting unique elements in the scripts.
5. See Also, with links to conceptual information or good tutorials to try as a next step.
Separate setup (prerequisites) from usage from code development. These are each different activities that engage different areas of the brain. Trying to think of all three elements at once leads to confusion and headaches.
## Description
![Description](img/tut-struct1.png)
List what the sample demonstrates. If possible, each example should describe the steps to accomplish specific related tasks. (For example, create a NFT Sell Offer, Accept a Sell Offer, Delete a Sell Offer.) There should be enough conceptual information to understand what the tutorial illustrates, with links to additional conceptual information, if needed.
## Prerequisites
![Prerequisites](img/tut-struct2.png)
Provide links to any required software and to all of the example code needed to run the tutorial. If necessary, give simple instructions for using third-party tools, but provide a link to the source website for the customer to do a deeper dive at their leisure.
## Usage Example
![Usage](img/tut-struct3.png)
Start by providing a finished, working example of the tutorial application. This is an opportunity for immediate success working with the software to solve a problem.
Use screenshots for each step of the tutorial these allow the user to understand the tutorial without having to run the code themselves. Of course we _want_ them to run the code, but this gives them a choice.
Describe the sunny day scenario. The application should run without problems if there is an uninterrupted connection to the internet. Dont provide a lot of troubleshooting information, unless its pertinent to the tutorial.
## Code Walkthrough
![Code Walkthrough](img/tut-struct4.png)
Walk through the code, one chunk at a time. Dont belabor topics that have been discussed in earlier examples. Provide sample code, but dont provide exhaustive explanations for how to program underlying platforms like HTML syntax unless there is something unique to the implementation.
An important thing to emphasize is that every interaction with the XRPL is either a transaction or a request, and that all transactions and requests are essentially the same. The sample code we provide shows how to prepare the transaction or request, and how to process the returned results. Knowing how to submit and respond to one transaction or request gives a pretty good idea for how to submit and respond to any transaction or request.
(Technically there is third category, similar to a request: a notification from a subscription stream. See [Subscription Methods](subscription-methods.html).)
## See Also
![See Also](img/tut-struct5.png)
At the end of the tutorial, provide links to additional resources, conceptual information, and any tutorials that would be a sensible next step in the learning journey.

View File

@@ -20,7 +20,6 @@ Example {{currentpage.name}} JSON
} }
``` ```
Unlike full-fledged [ledger entries](ledger-object-types.html), `NFToken` has no field to identify the object type or current owner of the object. `NFToken` objects are grouped into pages that implicitly define the object type and identify the owner. Unlike full-fledged [ledger entries](ledger-object-types.html), `NFToken` has no field to identify the object type or current owner of the object. `NFToken` objects are grouped into pages that implicitly define the object type and identify the owner.
@@ -37,13 +36,10 @@ This composite field uniquely identifies a token, and consists of the following
4. A 32-bit issuer-specified [`NFTokenTaxon`](https://www.merriam-webster.com/dictionary/taxon) 4. A 32-bit issuer-specified [`NFTokenTaxon`](https://www.merriam-webster.com/dictionary/taxon)
5. An (automatically generated) monotonically increasing 32-bit sequence number. 5. An (automatically generated) monotonically increasing 32-bit sequence number.
![Token ID Breakdown](img/nftoken1.png "Token ID Breakdown") ![Token ID Breakdown](img/nftoken1.png "Token ID Breakdown")
The 16-bit flags, transfer fee fields, the 32-bit `NFTokenTaxon`, and the sequence number fields are stored in big-endian format. The 16-bit flags, transfer fee fields, the 32-bit `NFTokenTaxon`, and the sequence number fields are stored in big-endian format.
## NFToken Flags ## NFToken Flags
Flags are properties or other options associated with the `NFToken` object. Flags are properties or other options associated with the `NFToken` object.
@@ -59,36 +55,29 @@ Flags are properties or other options associated with the `NFToken` object.
`NFToken` flags are immutable: they can only be set during the [NFTokenMint transaction][] and cannot be changed later. `NFToken` flags are immutable: they can only be set during the [NFTokenMint transaction][] and cannot be changed later.
### Example ### Example
The example sets three flags: `lsfBurnable` (`0x0001`), `lsfOnlyXRP` (`0x0002`), `lsfTransferable` (`0x0008`). 1+2+8 = 11, or `0x000B` in big endian format. The example sets three flags: `lsfBurnable` (`0x0001`), `lsfOnlyXRP` (`0x0002`), `lsfTransferable` (`0x0008`). 1+2+8 = 11, or `0x000B` in big endian format.
![Flags](img/nftokena.png "Flags") ![Flags](img/nftokena.png "Flags")
### TransferFee ### TransferFee
<!-- SPELLING_IGNORE: transferfee --> <!-- SPELLING_IGNORE: transferfee -->
The `TransferFee` value specifies the percentage fee, in units of 1/100,000, charged by the issuer for secondary sales of the token. Valid values for this field are between 0 and 50,000, inclusive. A value of 1 is equivalent to 0.001% or 1/10 of a basis point (bps), allowing transfer rates between 0% and 50%. The `TransferFee` value specifies the percentage fee, in units of 1/100,000, charged by the issuer for secondary sales of the token. Valid values for this field are between 0 and 50,000, inclusive. A value of 1 is equivalent to 0.001% or 1/10 of a basis point (bps), allowing transfer rates between 0% and 50%.
### Example ### Example
This value sets the transfer fee to 314, or 0.314%. This value sets the transfer fee to 314, or 0.314%.
![Transfer Fee](img/nftokenb.png "Transfer Fee") ![Transfer Fee](img/nftokenb.png "Transfer Fee")
### Issuer Identification ### Issuer Identification
The third section of the `NFTokenID` is a big endian representation of the issuers public address. The third section of the `NFTokenID` is a big endian representation of the issuers public address.
![Issuer Address](img/nftokenc.png "Issuer Address") ![Issuer Address](img/nftokenc.png "Issuer Address")
### NFTokenTaxon ### NFTokenTaxon
<!-- SPELLING_IGNORE: nftokentaxon --> <!-- SPELLING_IGNORE: nftokentaxon -->
@@ -114,38 +103,28 @@ The URI field points to the data or metadata associated with the `NFToken`. This
**Caution:** The URI is immutable, so no one can update it if, for example, it links to a website that no longer exists. **Caution:** The URI is immutable, so no one can update it if, for example, it links to a website that no longer exists.
# Retrieving NFToken Data and Metadata # Retrieving NFToken Data and Metadata
To minimize the footprint of `NFTokens` without sacrificing functionality or imposing unnecessary restrictions, XRPL NFTs do not have arbitrary data fields. Instead, data is maintained separately and referenced by the `NFToken`. The URI provides a reference to immutable content for the `Hash` and any mutable data for the `NFToken` object. To minimize the footprint of `NFTokens` without sacrificing functionality or imposing unnecessary restrictions, XRPL NFTs do not have arbitrary data fields. Instead, data is maintained separately and referenced by the `NFToken`. The URI provides a reference to immutable content for the `Hash` and any mutable data for the `NFToken` object.
The `URI` field is especially useful for referring to non-traditional Peer-to-Peer (P2P) URLs. For example, a minter that stores `NFToken` data or metadata using the Inter Planetary File System (IPFS) can use the `URI` field to refer to data on IPFS in different ways, each of which is suited to different use-cases. For more context on types of IPFS links that can be used to store NFT data, see [Best Practices for Storing NFT Data using IPFS](https://docs.ipfs.io/how-to/best-practices-for-nft-data/#types-of-ipfs-links-and-when-to-use-them), The `URI` field is especially useful for referring to non-traditional Peer-to-Peer (P2P) URLs. For example, a minter that stores `NFToken` data or metadata using the Inter Planetary File System (IPFS) can use the `URI` field to refer to data on IPFS in different ways, each of which is suited to different use-cases. For more context on types of IPFS links that can be used to store NFT data, see [Best Practices for Storing NFT Data using IPFS](https://docs.ipfs.io/how-to/best-practices-for-nft-data/#types-of-ipfs-links-and-when-to-use-them),
An alternative to the URI approach is for issuers of `NFToken` objects to set the `Domain` field of their issuing account to the correct domain, and offer an API for clients that want to lookup the data or metadata associated with a particular `NFToken`. Note that using this mechanism _requires_ the minter to acquire a domain name and set the domain name for their minting account, but does not require the minter to necessarily run a server nor other service to provide the ability to query this data; instead, a minter can "redirect" queries to a data provider (for example, to a marketplace, registry or other service).
Your implementation should first attempt to check for the presence of the `URI` field to retrieve the associated data or metadata. If the `URI` field does not exist, the implementation should check for the presence of `Domain` field. If neither field exists, nothing happens. Implementations must be prepared to handle HTTP redirections (for example, using HTTP responses 301, 302, 307 and 308) from the URI.
## TXT Record Format ## TXT Record Format
The format for a text record is as follows. The format for a text record is as follows.
``` ```
xrpl-nft-data-token-info-v1 IN TXT "https://host.example.com/api/token-info/{nftokenid}" xrpl-nft-data-token-info-v1 IN TXT "https://host.example.com/api/token-info/{nftokenid}"
``` ```
Replace the string `{nftokenid}` with the requested `NFTokenID` as a 64-byte hex string when you attempt to query information. Replace the string `{nftokenid}` with the requested `NFTokenID` as a 64-byte hex string when you attempt to query information.
Your implementation should check for the presence of `TXT` records and use those query strings if present. If no string is present, implementations should attempt to use a default URL. Assuming the domain is _example.com_, the default URL would be: Your implementation should check for the presence of `TXT` records and use those query strings if present. If no string is present, implementations should attempt to use a default URL. Assuming the domain is _example.com_, the default URL would be:
``` ```
https://example.com/.well-known/xrpl-nft/{nftokenid} https://example.com/.well-known/xrpl-nft/{nftokenid}
``` ```
You create `NFToken` objects using the `NFTokenMint` transaction. You can optionally destroy `NFToken` objects using the `NFTokenBurn` transaction. You create `NFToken` objects using the `NFTokenMint` transaction. You can optionally destroy `NFToken` objects using the `NFTokenBurn` transaction.
<!--{# common link defs #}--> <!--{# common link defs #}-->

View File

@@ -1053,6 +1053,11 @@ pages:
targets: targets:
- ja - ja
- md: concepts/consensus-network/amendments/contribute-code-flow.md
targets:
- en
- ja
- md: concepts/consensus-network/amendments/known-amendments.md - md: concepts/consensus-network/amendments/known-amendments.md
targets: targets:
- en - en
@@ -1228,8 +1233,8 @@ pages:
html: tutorials.html html: tutorials.html
parent: docs.html parent: docs.html
top_nav_grouping: Article Types top_nav_grouping: Article Types
template: pagetype-category.html.jinja template: pagetype-tutorials.html.jinja
blurb: Get step-by-step guidance to perform common tasks with the XRP Ledger. blurb: The XRP Ledger tutorials walk you through the steps to learn and get started with the XRP Ledger and to use the ledger for advanced use cases.
targets: targets:
- en - en
@@ -1237,7 +1242,7 @@ pages:
html: tutorials.html html: tutorials.html
parent: docs.html parent: docs.html
top_nav_grouping: Article Types top_nav_grouping: Article Types
template: pagetype-category.html.jinja template: pagetype-tutorials.html.jinja
blurb: XRP Ledgerで一般的なタスクを実行するためのステップバイステップのガイダンスを紹介します。 blurb: XRP Ledgerで一般的なタスクを実行するためのステップバイステップのガイダンスを紹介します。
targets: targets:
- ja - ja
@@ -4488,7 +4493,7 @@ pages:
html: contribute-code-to-rippled.html html: contribute-code-to-rippled.html
template: pagetype-redirect.html.jinja template: pagetype-redirect.html.jinja
nav_omit: true nav_omit: true
redirect_url: contribute-code.html redirect_url: contribute-code-flow.html
targets: targets:
- en - en
@@ -4496,7 +4501,7 @@ pages:
html: contribute-code-to-rippled.html html: contribute-code-to-rippled.html
template: pagetype-redirect.html.jinja template: pagetype-redirect.html.jinja
nav_omit: true nav_omit: true
redirect_url: contribute-code.html redirect_url: contribute-code-flow.html
targets: targets:
- ja - ja
@@ -4504,7 +4509,7 @@ pages:
html: contribute-code-to-ripple-lib.html html: contribute-code-to-ripple-lib.html
template: pagetype-redirect.html.jinja template: pagetype-redirect.html.jinja
nav_omit: true nav_omit: true
redirect_url: contribute-code.html redirect_url: contribute-code-flow.html
targets: targets:
- en - en
@@ -4512,7 +4517,7 @@ pages:
html: contribute-code-to-ripple-lib.html html: contribute-code-to-ripple-lib.html
template: pagetype-redirect.html.jinja template: pagetype-redirect.html.jinja
nav_omit: true nav_omit: true
redirect_url: contribute-code.html redirect_url: contribute-code-flow.html
targets: targets:
- ja - ja
@@ -4732,6 +4737,24 @@ pages:
- en - en
- ja - ja
# TODO: translate
- md: contributing/tutorial-guidelines.md
html: tutorial-guidelines.html
parent: contribute-code.html
top_nav_omit: true
targets:
- en
- ja
# TODO: translate
- md: contributing/tutorial-structure.md
html: tutorial-structure.html
parent: tutorial-guidelines.html
top_nav_omit: true
targets:
- en
- ja
- name: Events - name: Events
html: events.html html: events.html
parent: contribute.html parent: contribute.html

Binary file not shown.

After

Width:  |  Height:  |  Size: 351 KiB

BIN
img/tut-struct1.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 84 KiB

BIN
img/tut-struct2.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 44 KiB

BIN
img/tut-struct3.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 77 KiB

BIN
img/tut-struct4.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 68 KiB

BIN
img/tut-struct5.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

View File

@@ -172,6 +172,16 @@
h1 { h1 {
font-size: 3.875rem; font-size: 3.875rem;
} }
.arrow-purple::after {
content: url(../img/icons/arrow-right-purple.svg);
}
.documentation-index:hover, .documentation-index::after {
color: $purple;
text-decoration: none !important;
background: none !important;
}
} }
@media (max-width: 765px) { @media (max-width: 765px) {

View File

@@ -921,6 +921,7 @@
position: relative; position: relative;
z-index: 5; z-index: 5;
width: 100%; width: 100%;
transform: translateY(0%);
p a { p a {
text-decoration: none; text-decoration: none;

117
styles/_tutorials.scss Normal file
View File

@@ -0,0 +1,117 @@
$footer-images: 3col-magenta-orange, 3col-green-blue, 3col-orange, 3col-purple, 3-col-green-purple, 3col-magenta, 3col-light-green, 3col-orange-yellow, 3-col-dark-blue;
/* Tutorials ---------------------------------------------------------------- */
@mixin card-footer-color($offset){
$index: 0;
@for $i from $offset + 1 through length($footer-images) {
$index: $index + 1;
.card:nth-child(9n + #{$index}) .card-footer {
background-image: url("../img/cards/#{nth($footer-images, $i)}.svg");
}
}
@for $i from 1 through $offset + 1 {
$index: $index + 1;
.card:nth-child(9n + #{$index}) .card-footer {
background-image: url("../img/cards/#{nth($footer-images, $i)}.svg");
}
}
}
.tutorial-content {
#beginner-cards {
@include card-footer-color(0);
}
#sdk-cards {
@include card-footer-color(2);
}
#use-cases-cards {
@include card-footer-color(4);
}
#servers-cards {
@include card-footer-color(6);
}
#businesses-cards {
@include card-footer-color(8);
}
}
.tutorial-card-grid {
grid-gap: 40px !important;
row-gap: 0 !important;
&.card-grid {
.card {
margin-bottom: 2.5rem;
background-position: bottom;
background-repeat: no-repeat;
background-size: contain;
padding: 0;
min-height: 0;
.card-body {
padding: 32px;
}
.card-title {
margin-bottom: 16px;
margin-top: 0;
&.external-link::after {
background-size: 0.9rem;
vertical-align: middle;
margin-left: 12px;
margin-bottom: 12px;
margin-right: 10px;
width: 1.5rem;
}
&.nav-link {
padding: 0;
}
}
.card-footer {
font-size: 0;
padding: 1rem;
background-position: bottom;
background-repeat: no-repeat;
background-size: cover;
border-top: 0;
}
}
a {
text-decoration: none;
}
code {
color: $green-600;
background-color: $green-1000;
border-radius: 4px;
padding-left: 4px;
padding-right: 4px;
}
.card-icon-container {
width: 50px;
height: 50px;
background: $gray-600;
display: flex;
justify-content: center;
align-items: center;
border-radius: 50%;
margin-bottom: 12px;
img {
width: 70%;
height: 70%;
}
}
}
}

View File

@@ -985,4 +985,14 @@ $placeholder-color: $gray-600;
} }
.tutorial-card-grid {
code {
background-color: $green-100;
}
.card-icon-container {
background: $gray-300;
}
}

View File

@@ -4,9 +4,9 @@
"node-sass": "^7.0.0" "node-sass": "^7.0.0"
}, },
"scripts": { "scripts": {
"build-css": "node-sass --include-path scss xrpl.scss ../assets/css/devportal2022-v17.css --output-style compressed", "build-css": "node-sass --include-path scss xrpl.scss ../assets/css/devportal2022-v18.css --output-style compressed",
"build-css-out": "node-sass --include-path scss xrpl.scss ../out/assets/css/devportal2022-v17.css --output-style compressed --source-map true", "build-css-out": "node-sass --include-path scss xrpl.scss ../out/assets/css/devportal2022-v18.css --output-style compressed --source-map true",
"build-css-watch-out": "node-sass --recursive --watch --include-path scss xrpl.scss ../out/assets/css/devportal2022-v17.css --output-style compressed --source-map true" "build-css-watch-out": "node-sass --recursive --watch --include-path scss xrpl.scss ../out/assets/css/devportal2022-v18.css --output-style compressed --source-map true"
}, },
"dependencies": { "dependencies": {
"sass": "^1.26.10" "sass": "^1.26.10"

View File

@@ -69,6 +69,7 @@ $line-height-base: 1.5;
@import "_video.scss"; @import "_video.scss";
//@import "_top-banner.scss"; //@import "_top-banner.scss";
@import "_toml-checker.scss"; @import "_toml-checker.scss";
@import "_tutorials.scss";
@import "_docs-landing.scss"; @import "_docs-landing.scss";
// Light/Dark theme settings --------------------------------------------------- // Light/Dark theme settings ---------------------------------------------------

View File

@@ -52,7 +52,7 @@
{% if target.lang=="ja" %} {% if target.lang=="ja" %}
<link href="{{currentpage.prefix}}assets/css/fonts-ja.css" rel="stylesheet" /> <link href="{{currentpage.prefix}}assets/css/fonts-ja.css" rel="stylesheet" />
{% endif %} {% endif %}
<link href="{{currentpage.prefix}}assets/css/devportal2022-v17.css" rel="stylesheet" /> <link href="{{currentpage.prefix}}assets/css/devportal2022-v18.css" rel="stylesheet" />
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@docsearch/css@3" /> <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@docsearch/css@3" />

View File

@@ -413,7 +413,7 @@
</div> </div>
</section><!-- Browse by recommended and Generate Testnet Credentials --> </section><!-- Browse by recommended and Generate Testnet Credentials -->
<section class="container-new"> <section class="container-new">
<a href="./docs-index.html" class="ml-auto">{% trans %}See full documenation index{% endtrans %}</a> <a href="./docs-index.html" class="btn-arrow arrow-purple documentation-index mr-auto">{% trans %}See full documentation index{% endtrans %}</a>
</section> </section>
{% endblock %} {% endblock %}

View File

@@ -0,0 +1,213 @@
{% extends "base.html.jinja" %}
{% block mainclasses %}landing landing-children padded-main{% endblock %}
{% set categoriesTutorials = [
{
"id": "beginner",
"title": "Beginner Tutorials",
"description": "",
"children": [
{
"title": "Quickstart",
"description": "This Quickstart tutorial walks you through a test harness interface to try out the XRP Ledger.",
"href": "xrpl-quickstart.html",
"img": "",
},
]
},
{
"id": "sdk",
"title": "Get started with SDKs",
"description": "These tutorials walk you through the basics of building a very simple XRP Ledger-connected application using SDKs.",
"children": [
{
"title": "Python",
"description": "Using xrpl.py, a pure Python library.",
"href": "get-started-using-python.html",
"img": "./assets/img/logos/python.svg",
"external": true,
},
{
"title": "Java",
"description": "Using xrpl4j, a pure Java library.",
"href": "get-started-using-java.html",
"img": "./assets/img/logos/java.svg",
"external": true,
},
{
"title": "Javascript",
"description": "Using the xrpl.js client library.",
"href": "get-started-using-javascript.html",
"img": "./assets/img/logos/javascript.svg",
"external": true,
},
{
"title": "HTTP & Websocket APIs",
"description": "Access the XRP Ledger directly through the APIs of its core server.",
"href": "http-websocket-apis.html",
"img": "./assets/img/logos/globe.svg",
"external": true,
},
]
},
{
"id": "use-cases",
"title": "XRP Ledger Use Cases",
"description": "",
"children": [
{
"title": "Payments",
"description": "Send and receive payments on the XRP Ledger.",
"href": "payment.html",
"img": "",
},
{
"title": "Tokens",
"description": "Create and trade fungible and non-fungible tokens on the XRP Ledger.",
"href": "tokens.html",
"img": "",
},
]
},
{
"id": "servers",
"title": "Manage the XRP Ledger Servers",
"description": "",
"children": [
{
"title": "Install rippled Server",
"description": "These tutorials describe the steps to install and update the core XRP Ledger server.",
"href": "install-rippled.html",
"img": "",
"external": true,
},
{
"title": "Configure rippled Server",
"description": "These tutorials describe the steps to customize your <code>rippled</code> server configuration.",
"href": "configure-rippled.html",
"img": "",
"external": true,
},
{
"title": "Run rippled in Standalone Mode",
"description": "These tutorials describe the steps to run <code>rippled</code> in stand-alone mode and test features without a full network.",
"href": "use-stand-alone-mode.html",
"img": "",
"external": true,
},
{
"title": "Install Clio Server",
"description": "This tutorial describes the steps to install the Clio server on Ubuntu platform.",
"href": "install-clio-on-ubuntu.html",
"img": "",
},
]
},
{
"id": "businesses",
"title": "XRP Ledger Businesses",
"description": "This section demonstrates how to follow various best practices for running businesses that interface with the XRP Ledger, such as exchanges listing XRP and gateways issuing currency in the XRP Ledger.",
"children": [
{
"title": "List XRP as an Exchange",
"description": "Run a digital asset exchange? Follow these steps to add XRP.",
"href": "list-xrp-as-an-exchange.html",
"img": "",
},
{
"title": "Become a Stablecoin Issuer",
"description": "Stablecoin issuers link tokens in the XRP Ledger to assets in the outside world.",
"href": "become-an-xrp-ledger-gateway.html#become-a-stablecoin-issuer",
"img": "",
},
]
},
]%}
{% block right_sidebar %}
<div class="tutorial-sidebar">
<a class="with-caret expander collapsed d-lg-none" id="toc-expander" role="button" data-toggle="collapse" data-target="#page-toc-wrapper" aria-expanded="false">
Page Toolbar
<span class="chevron"><span></span><span></span></span>
</a>
<div id="page-toc-wrapper" class="collapse d-lg-block">
<ul class="page-toc nav flex-column" role="directory">
<li class="nav-item"><a class="nav-link" href="#main-page-header">Tutorials</a></li>
{% for c in categoriesTutorials %}
<li class="nav-item"><a class="nav-link" href="#{{c.id}}">{{c.title}}</a></li>
{% endfor %}
</ul>
</div>
</div>
{% endblock %}
{% block main %}
{% if content %}
<section class="pt-3 p-md-3">
<article class="content">
{{ content }}
{% set show_blurbs = True %}
{% set depth= 1 %}
{% include 'children.html' %}
</article>
</section>
{% else %}
<section class="pt-3 p-md-3">
<article class="content">
<h1 id="main-page-header">{{ currentpage.name }}</h1>
{% if currentpage.blurb != target.blurb %}<p class="blurb">{{ currentpage.blurb }}</p>{% endif %}
{% set show_blurbs = True %}
{% set depth= 1 %}
{% macro tutorialCard(title, description, href, img, external) %}
<a class="card" href="{{href}}" target="_blank">
<div class="card-body">
{% if img %}
<div class="card-icon-container">
<img src="{{img}}" alt="{{title}} Screenshot" />
</div>
{% endif %}
{% if external %}
<h4 class="card-title h5 nav-link external-link">{{title}}</h4>
{% else %}
<h4 class="card-title h5">{{title}}</h4>
{% endif %}
<p class="card-text">{{description}}</p>
</div>
<div class="card-footer">&nbsp;</div>
</a>
{% endmacro %}
<div class="tutorial-content">
{% for category in categoriesTutorials %}
<h5 id="{{category.id}}">{{category.title}}</h5>
<p>{{category.description}}</p>
<div id="{{category.id}}-cards" class="card-grid card-grid-3xN tutorial-card-grid">
{% for child in category.children %}
{{ tutorialCard(child.title, child.description, child.href, child.img, child.external)}}
{% endfor %}
</div>
{% endfor %}
</div>
</article>
</section>
{% endif %}
{% endblock %}
{% block analytics %}
{% from "macro-get_funnel.jinja" import get_funnel %}
<script type="application/javascript">
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
"event": "page_info",
"page_type": "Hub Page",
"page_group": "Docs",
"page_funnel": "{{get_funnel(pages, currentpage)}}",
"page_labels": {{currentpage.labels or []}}
})
</script>
{% endblock analytics %}