Control Flow
Conditional and logical operators for controlling execution flow in workflows and visitors.
Keywords
if- Logical condition (in visitor contexts)when- Temporal/state condition (in visitor contexts)while- Loop conditionfor- Iterationin- Collection membershipof- Collection iterationand- Logical ANDor- Logical ORnot- Logical NOT
State-Based Control Flow
In Aexol, control flow is primarily managed through:
- Workflow state transitions - Define explicit paths between states
- Visitor nested blocks - Represent state changes in user journeys
- Named state blocks - Show available capabilities in different contexts
Workflow State Transitions
workflow OrderFlow {
state pending -> processing, cancelled
state processing -> shipped, failed
state shipped -> delivered
state failed -> retry, refunded
}
✨ Edit in StudioVisitor State Blocks
visitor {
"browse"
"login" {
logged_in {
"view profile"
"manage account"
"logout"
}
}
}
✨ Edit in StudioConditional Blocks in Visitors
Basic Conditional Patterns
visitor {
"start process" {
processing {
"validate data"
"transform data"
"complete process" {
completed {
"view results"
"export data"
}
}
}
}
}
✨ Edit in StudioBranching Paths
visitor {
"submit application" {
reviewing {
"check status"
"approve application" {
approved {
"access benefits"
}
}
"reject application" {
rejected {
"resubmit"
}
}
}
}
}
✨ Edit in StudioLogical Keywords (Conceptual)
While the new Aexol syntax uses string-based capabilities, logical concepts still apply to workflow design:
and - Multiple Requirements
Express with nested blocks - all parent capabilities must be available:
visitor {
"login" {
authenticated {
"verify email" {
verified {
"access premium features"
}
}
}
}
}
✨ Edit in Studioor - Alternative Paths
Express with multiple workflow transitions:
workflow AccessFlow {
state start -> login, oauth
state login -> dashboard
state oauth -> dashboard
state dashboard
}
✨ Edit in StudioLoop and Iteration Patterns
Retry Loops in Workflows
workflow ProcessFlow {
state processing -> success, failed
state failed -> retry
state retry -> processing
state success
}
✨ Edit in StudioIterative Processing
visitor {
"process batch" {
processing {
"process item"
"mark complete"
"continue to next"
}
}
}
✨ Edit in StudioReal-World Examples
Access Control
workflow AccessFlow {
state anonymous -> authenticated
state authenticated -> authorized, unauthorized
state authorized -> access_granted
state unauthorized -> denied
}
visitor {
"view public content"
"login" {
authenticated {
"view protected content"
"verify permissions" {
authorized {
"access admin panel"
"manage resources"
}
}
}
}
}
✨ Edit in StudioOrder Processing
workflow OrderFlow {
state cart -> checkout
state checkout -> payment
state payment -> confirmed, failed
state failed -> retry, cancelled
state retry -> payment
state confirmed -> shipped
state shipped -> delivered
}
visitor {
"browse products"
"add to cart"
"checkout" {
checking_out {
"enter shipping"
"enter payment"
"confirm order" {
order_placed {
"track order"
"view order details"
}
}
}
}
}
✨ Edit in StudioContent Moderation
workflow ModerationFlow {
state submitted -> review
state review -> approved, rejected, flagged
state flagged -> human_review
state human_review -> approved, rejected
state approved -> published
state rejected -> archived
}
agent ContentModerator {
"receive content"
"analyze content"
"approve safe content"
"reject violations"
"flag uncertain content"
"escalate to human review"
}
✨ Edit in StudioWorkflow Automation
workflow AutomationFlow {
state triggered -> validating
state validating -> processing, error
state processing -> complete, error
state error -> retry, failed
state retry -> validating
state complete
state failed
}
agent AutomationRunner {
"trigger workflow"
"validate inputs"
"process task"
"handle errors"
"retry on failure"
"report completion"
}
✨ Edit in StudioBest Practices
Condition Clarity
-
Use descriptive state names
- Good:
payment_verified,user_authenticated - Avoid:
state1,check1
- Good:
-
Model conditions as states
✨ Edit in Studioworkflow ValidationFlow { state pending -> validating state validating -> valid, invalid state valid -> processing state invalid -> rejected } -
Use nested blocks for context
✨ Edit in Studiovisitor { "login" { authenticated { "access features" # Only available when authenticated } } }
Workflow Design Patterns
Guard Pattern
workflow GuardedFlow {
state start -> validation
state validation -> authorized, unauthorized
state authorized -> processing
state unauthorized -> denied
state processing -> complete
}
✨ Edit in StudioFallback Pattern
workflow FallbackFlow {
state primary -> success, fallback
state fallback -> success, emergency
state emergency -> success, failed
state success
state failed
}
✨ Edit in StudioProgressive Enhancement
visitor {
# Basic access
"view content"
"login" {
logged_in {
# Enhanced access
"save favorites"
"comment"
"upgrade" {
premium {
# Premium access
"download content"
"access archive"
}
}
}
}
}
✨ Edit in StudioControl Flow Summary
| Concept | Implementation |
|---|---|
| Conditions | Workflow states |
| Branching | Multiple transitions |
| Loops | Circular state transitions |
| Sequential | Linear workflow states |
| Context | Visitor nested blocks |
| Guards | Validation states |
Related Keywords
workflow- State machines for flow controlvisitor- User journey definitionsagent- Autonomous actions
Next Steps
- Learn about Workflows for state management
- Explore Visitors with nested control flow
- See Complete Examples with control flow patterns
