Skip to content

Add component directory structure and best practices to moqui skills prompt #161

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
yash-verma5 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add component directory structure and best practices to moqui skills prompt #161

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions moqui-framework/bestpractices/skills-md-prompt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,12 +30,32 @@ Mandatory content to include:
13. Prefer Groovy closures over multiple iterates when it improves clarity (filter/search/sort).
14. Always use `date-filter` for entities with `fromDate`/`thruDate`.
15. If Groovy is more efficient, use a `script` tag in the XML service.
16. Adhere to the standard Moqui Component Directory Structure (entity, service, screen, data, src, etc.).

The output must be a single `SKILLS.md` file with clear sections and bullet lists, covering all items above. Include any additional best practices deduced from OrderRouting and related services (examples: use-iterator for large result sets, service call error handling, transaction timeouts, semaphores, SQL templates with FTL, etc).
```

## Best practices inventory (must appear in SKILLS.md)

### Component Workflow & Directory Structure
- **entity/ (Data Model)**
- Read here to understand the schema. Write new `<entity>` and `<view-entity>` definitions here.
- Define schema **first**. Never put entity definitions inside services or screens.
- **service/ (Business Logic & API)**
- Write Service Definitions (.xml). Use inline `<actions>` for standard logic (CRUD, orchestration).
- Follow "Definition First" — define `in-parameters` and `out-parameters` before writing any implementation logic.
- **screen/ (User Interface)**
- Write Screen and Form definitions (.xml).
- Keep screens logic-free. Delegate all processing to services immediately.
- **src/ (Complex Implementation)**
- Write compiled Java/Groovy classes here.
- Use strictly for algorithmic logic, heavy data processing, or external API integrations that are too complex for XML Actions.
- **data/ (System Data)**
- Write `Seed` (Types, Enums) and `Demo` data here.
- Separate data by type (`TypeData.xml`, `DemoData.xml`) rather than one giant file.
- **component.xml (Dependencies)**
- Write new `<depends-on>` entries here if you use resources from another component.

### Service naming
- Use existing verbs already in the codebase; do not invent ad-hoc verbs.
- Use domain nouns from entity/model names in PascalCase.
Expand Down