mukan-ignite/ignite/cmd/scaffold_list.go
Mukan Erkin Törük c32551b6f7
Some checks failed
Docs Deploy / build_and_deploy (push) Has been cancelled
Generate Docs / cli (push) Has been cancelled
Generate Config Doc / cli (push) Has been cancelled
Go formatting / go-formatting (push) Has been cancelled
Check links / markdown-link-check (push) Has been cancelled
Integration / pre-test (push) Has been cancelled
Integration / test on (push) Has been cancelled
Integration / status (push) Has been cancelled
Lint / Lint Go code (push) Has been cancelled
Test / test (ubuntu-latest) (push) Has been cancelled
refactor: replace all github.com upstream refs with git.cw.tr/mukan-network
2026-05-11 03:36:24 +03:00

112 lines
4.2 KiB
Go

package ignitecmd
import (
"github.com/spf13/cobra"
"git.cw.tr/mukan-network/mukan-ignite/ignite/services/scaffolder"
)
// NewScaffoldList returns a new command to scaffold a list.
func NewScaffoldList() *cobra.Command {
c := &cobra.Command{
Use: "list NAME [field]...",
Short: "CRUD for data stored as an array",
Long: `The "list" scaffolding command is used to generate files that implement the
logic for storing and interacting with data stored as a list in the blockchain
state.
The command accepts a NAME argument that will be used as the name of a new type
of data. It also accepts a list of FIELDs that describe the type.
The interaction with the data follows the create, read, updated, and delete
(CRUD) pattern. For each type three Cosmos SDK messages are defined for writing
data to the blockchain: MsgCreate{Name}, MsgUpdate{Name}, MsgDelete{Name}. For
reading data two queries are defined: {Name} and {Name}All. The type, messages,
and queries are defined in the "proto/" directory as protocol buffer messages.
Messages and queries are mounted in the "Msg" and "Query" services respectively.
When messages are handled, the appropriate keeper methods are called. By
convention, the methods are defined in
"x/{moduleName}/keeper/msg_server_{name}.go". Helpful methods for getting,
setting, removing, and appending are defined in the same "keeper" package in
"{name}.go".
The "list" command essentially allows you to define a new type of data and
provides the logic to create, read, update, and delete instances of the type.
For example, let's review a command that generates the code to handle a list of
posts and each post has "title" and "body" fields:
ignite scaffold list post title body
This provides you with a "Post" type, MsgCreatePost, MsgUpdatePost,
MsgDeletePost and two queries: Post and PostAll. The compiled CLI, let's say the
binary is "blogd" and the module is "blog", has commands to query the chain (see
"blogd q blog") and broadcast transactions with the messages above (see "blogd
tx blog").
The code generated with the list command is meant to be edited and tailored to
your application needs. Consider the code to be a "skeleton" for the actual
business logic you will implement next.
By default, all fields are assumed to be strings. If you want a field of a
different type, you can specify it after a colon ":". The following types are
supported: string, bool, int, uint, coin, array.string, array.int, array.uint,
array.coin. An example of using field types:
ignite scaffold list pool amount:coin tags:array.string height:int
For detailed type information use ignite scaffold type --help
"Index" indicates whether the type can be used as an index in
"ignite scaffold map".
Ignite also supports custom types:
ignite scaffold list product-details name desc
ignite scaffold list product price:coin details:ProductDetails
In the example above the "ProductDetails" type was defined first, and then used
as a custom type for the "details" field.
Your chain will accept custom types in JSON-notation:
exampled tx example create-product 100coin '{"name": "x", "desc": "y"}' --from alice
By default the code will be scaffolded in the module that matches your project's
name. If you have several modules in your project, you might want to specify a
different module:
ignite scaffold list post title body --module blog
By default, each message comes with a "creator" field that represents the
address of the transaction signer. You can customize the name of this field with
a flag:
ignite scaffold list post title body --signer author
It's possible to scaffold just the getter/setter logic without the CRUD
messages. This is useful when you want the methods to handle a type, but would
like to scaffold messages manually. Use a flag to skip message scaffolding:
ignite scaffold list post title body --no-message
The "creator" field is not generated if a list is scaffolded with the
"--no-message" flag.
`,
Args: cobra.MinimumNArgs(1),
PreRunE: migrationPreRunHandler,
RunE: scaffoldListHandler,
}
flagSetPath(c)
flagSetClearCache(c)
c.Flags().AddFlagSet(flagSetYes())
c.Flags().AddFlagSet(flagSetScaffoldType())
return c
}
func scaffoldListHandler(cmd *cobra.Command, args []string) error {
return scaffoldType(cmd, args, scaffolder.ListType())
}