5fd68ce6bdb2ea55f24b221b888fe89166589a46
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| c100d839f1 |
feat: implement persistent cart with database storage and proper exception handling
Implemented a complete shopping cart system with database persistence, replacing the previous stub implementation. The cart now properly stores items across sessions and follows the project's architecture patterns. Database Changes: - Add cart_items table with vendor_id, session_id, product_id, quantity, price_at_add - Create unique constraint to prevent duplicate items per session - Add indexes for session lookups and old cart cleanup - Run migration a2064e1dfcd4 to create cart_items table New Models & Schemas: - models/database/cart.py: CartItem SQLAlchemy model with relationships - models/schema/cart.py: Pydantic schemas for requests/responses * AddToCartRequest, UpdateCartItemRequest * CartResponse, CartItemResponse, CartOperationResponse, ClearCartResponse Exception Handling: - app/exceptions/cart.py: Cart-specific exceptions following project patterns * CartItemNotFoundException - item not found in cart * InsufficientInventoryForCartException - not enough inventory for cart operation * InvalidCartQuantityException - invalid quantity validation * CartValidationException - general cart validation * EmptyCartException - operations on empty cart * ProductNotAvailableForCartException - product unavailable - Updated app/exceptions/__init__.py to export cart exceptions Service Layer: - Implement cart_service.get_cart() - fetch cart from database with totals - Implement cart_service.add_to_cart() - create or update cart items with inventory checks - Implement cart_service.update_cart_item() - update quantity with validation - Implement cart_service.remove_from_cart() - delete cart item - Implement cart_service.clear_cart() - remove all items for session - Replace generic exceptions with cart-specific ones - Fix InsufficientInventoryException usage (was using wrong parameters) API Layer: - Update app/api/v1/shop/cart.py to use Pydantic schemas - Add response_model declarations to all endpoints - Add return type hints for type safety - Convert service dict responses to Pydantic models Features: - Cart items persist in database across server restarts - Inventory validation before adding/updating items - Price captured at time of adding to cart - Duplicate items update quantity instead of creating new entries - Full CRUD operations with proper error handling - Type-safe API with auto-generated OpenAPI documentation 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
|||
| 5a9f44f3d1 |
Complete shop API consolidation to /api/v1/shop/* with middleware-based vendor context
## API Migration (Complete)
### New Shop API Endpoints Created
- **Products API** (app/api/v1/shop/products.py)
- GET /api/v1/shop/products - Product catalog with pagination/search/filters
- GET /api/v1/shop/products/{id} - Product details
- **Cart API** (app/api/v1/shop/cart.py)
- GET /api/v1/shop/cart/{session_id} - Get cart
- POST /api/v1/shop/cart/{session_id}/items - Add to cart
- PUT /api/v1/shop/cart/{session_id}/items/{product_id} - Update quantity
- DELETE /api/v1/shop/cart/{session_id}/items/{product_id} - Remove item
- DELETE /api/v1/shop/cart/{session_id} - Clear cart
- **Orders API** (app/api/v1/shop/orders.py)
- POST /api/v1/shop/orders - Place order (authenticated)
- GET /api/v1/shop/orders - Order history (authenticated)
- GET /api/v1/shop/orders/{id} - Order details (authenticated)
- **Auth API** (app/api/v1/shop/auth.py)
- POST /api/v1/shop/auth/register - Customer registration
- POST /api/v1/shop/auth/login - Customer login (sets cookie at path=/shop)
- POST /api/v1/shop/auth/logout - Customer logout
- POST /api/v1/shop/auth/forgot-password - Password reset request
- POST /api/v1/shop/auth/reset-password - Password reset
**Total: 18 new shop API endpoints**
### Middleware Enhancement
Updated VendorContextMiddleware (middleware/vendor_context.py):
- Added is_shop_api_request() to detect /api/v1/shop/* routes
- Added extract_vendor_from_referer() to extract vendor from Referer header
- Supports path-based: /vendors/wizamart/shop/* → wizamart
- Supports subdomain: wizamart.platform.com → wizamart
- Supports custom domain: customshop.com → customshop.com
- Modified dispatch() to handle shop API specially (no longer skips)
- Vendor context now injected into request.state.vendor for shop API calls
### Frontend Migration (Complete)
Updated all shop templates to use new API endpoints:
- app/templates/shop/account/login.html - Updated login endpoint
- app/templates/shop/account/register.html - Updated register endpoint
- app/templates/shop/product.html - Updated 4 API calls (products, cart)
- app/templates/shop/cart.html - Updated 3 API calls (get, update, delete)
- app/templates/shop/products.html - Activated product loading from API
**Total: 9 API endpoint migrations across 5 templates**
### Old Endpoint Cleanup (Complete)
Removed deprecated /api/v1/public/vendors/* shop endpoints:
- Deleted app/api/v1/public/vendors/auth.py
- Deleted app/api/v1/public/vendors/products.py
- Deleted app/api/v1/public/vendors/cart.py
- Deleted app/api/v1/public/vendors/orders.py
- Deleted app/api/v1/public/vendors/payments.py (empty)
- Deleted app/api/v1/public/vendors/search.py (empty)
- Deleted app/api/v1/public/vendors/shop.py (empty)
Updated app/api/v1/public/__init__.py to only include vendor lookup endpoints:
- GET /api/v1/public/vendors/by-code/{code}
- GET /api/v1/public/vendors/by-subdomain/{subdomain}
- GET /api/v1/public/vendors/{id}/info
**Result: Only 3 truly public endpoints remain**
### Error Page Improvements
Updated all shop error templates to use base_url:
- app/templates/shop/errors/*.html (10 files)
- Updated error_renderer.py to calculate base_url from vendor context
- Links now work correctly for path-based, subdomain, and custom domain access
### CMS Route Handler
Added catch-all CMS route to app/routes/vendor_pages.py:
- Handles /{vendor_code}/{slug} for content pages
- Uses content_page_service for two-tier lookup (vendor override → platform default)
### Template Architecture Fix
Updated app/templates/shop/base.html:
- Changed x-data to use {% block alpine_data %} for component override
- Allows pages to specify custom Alpine.js components
- Enables page-specific state while extending shared shopLayoutData()
### Documentation (Complete)
Created comprehensive documentation:
- docs/api/shop-api-reference.md - Complete API reference with examples
- docs/architecture/API_CONSOLIDATION_PROPOSAL.md - Analysis of 3 options
- docs/architecture/API_MIGRATION_STATUS.md - Migration tracking (100% complete)
- Updated docs/api/index.md - Added Shop API section
- Updated docs/frontend/shop/architecture.md - New API structure and component pattern
## Benefits Achieved
### Cleaner URLs (~40% shorter)
Before: /api/v1/public/vendors/{vendor_id}/products
After: /api/v1/shop/products
### Better Architecture
- Middleware-driven vendor context (no manual vendor_id passing)
- Proper separation of concerns (public vs shop vs vendor APIs)
- Consistent authentication pattern
- RESTful design
### Developer Experience
- No need to track vendor_id in frontend state
- Automatic vendor context from Referer header
- Simpler API calls
- Better documentation
## Testing
- Verified middleware extracts vendor from Referer correctly
- Tested all shop API endpoints with vendor context
- Confirmed products page loads and displays products
- Verified error pages show correct links
- No old API references remain in templates
Migration Status: ✅ 100% Complete (8/8 success criteria met)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
|||
| fb3aa89086 |
feat: add CMS service layer and API endpoints
Implement complete CMS business logic and REST API:
Service Layer (content_page_service.py):
- get_page_for_vendor() - Two-tier lookup with fallback
- list_pages_for_vendor() - Merge vendor + platform pages
- create_page(), update_page(), delete_page() - CRUD operations
- Support for published/draft workflow
- Footer/header navigation filtering
API Endpoints:
Admin API (/api/v1/admin/content-pages):
- POST /platform - Create platform defaults
- GET /platform - List platform defaults
- GET / - List all pages with vendor filtering
- PUT /{id} - Update any page
- DELETE /{id} - Delete any page
Vendor API (/api/v1/vendor/{code}/content-pages):
- GET / - List available pages (vendor + platform merged)
- GET /overrides - List only vendor overrides
- POST / - Create vendor override
- PUT /{id} - Update vendor page
- DELETE /{id} - Delete vendor page
Shop API (/api/v1/shop/content-pages):
- GET /navigation - Get footer/header navigation pages
- GET /{slug} - Get specific page (public, with fallback)
All endpoints include proper authentication, authorization,
and validation using Pydantic schemas.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
