Add additional question text fields to form parameters #1888
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
There was a problem hiding this comment.
Pull Request Overview
This pull request refactors the form parameter handling in the Admin::FormsController to dynamically support up to 30 question text fields instead of hardcoding individual parameters. It also cleans up duplicate gem declarations in the Gemfile.
- Replaced hardcoded
:question_text_01through:question_text_20parameters with a dynamic approach using a range and mapping - Added a
MAX_QUESTIONSconstant set to 30 to define the upper limit for supported questions - Removed duplicate gem declarations in the Gemfile and fixed a typo in a comment
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| app/controllers/admin/forms_controller.rb | Refactored form parameters to dynamically generate question text fields up to MAX_QUESTIONS limit |
| Gemfile | Cleaned up duplicate gem declarations and fixed comment typo |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| :question_text_18, | ||
| :question_text_19, | ||
| :question_text_20, | ||
| *((1..MAX_QUESTIONS).map { |i| :"question_text_#{i.to_s.rjust(2, '0')}" }), |
There was a problem hiding this comment.
The dynamic parameter generation creates a new array on every request. Consider memoizing this result or defining it as a constant to avoid repeated computation.
Update HTTP status codes across controllers from :unprocessable_entity to :unprocessable_content to align with RFC 9110 standards. Also add RSpec profiling and ignore examples.txt file.
…ust error status codes in SubmissionsController; modify question limit in Form model; enhance accessibility in question type view.
…ecord, storage, and support versions to 8.0.2.1; upgrade various gem dependencies
…tent in submissions_controller
…tity in submissions_controller
- Implement Rust extension using Rutie for Ruby-Rust FFI - Add widget_renderer extension with modular architecture: - lib.rs: Main entry point and Ruby class binding - form_data.rs: Data structure parsing from Ruby hashes - template_renderer.rs: JavaScript template generation - Update Form model with fallback mechanism for backward compatibility - Add initializer for graceful extension loading - Include comprehensive documentation and test files - Configure build system with Cargo.toml and extconf.rb This implementation provides faster JavaScript widget generation while maintaining full compatibility with existing ERB-based rendering.
Co-authored-by: Copilot <[email protected]> Signed-off-by: Riley Seaburg <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Riley Seaburg <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Riley Seaburg <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Riley Seaburg <[email protected]>
- Implemented Rust-based widget renderer as Ruby extension using Rutie FFI - Embedded 4,020-line USWDS JavaScript bundle at compile time via include_str!() - Created comprehensive benchmarks comparing Rust vs ERB performance - Added HTTP and direct render benchmark endpoints - Compiled binary for x86-64 (Cloud Foundry deployment) Performance Results: - HTTP requests: 58.45ms (Rust) vs 707.9ms (ERB) = 12.1x faster - Direct render: 2.235ms (Rust) vs unable to benchmark ERB (context-dependent) - Throughput: 17.11 req/s (Rust) vs 1.41 req/s (ERB) - 91.7% reduction in response time Technical Implementation: - Rust extension compiled to 558KB .so file (x86-64) - Full backward compatibility with ERB (identical 4,189-line output) - Context-independent rendering (no Rails request/response required) - Automatic ERB fallback if Rust extension unavailable - Prefix computed from load_css in Rust (no Ruby model changes) Files Added: - BENCHMARK_RESULTS.md: Comprehensive performance analysis - RUST_WIDGET_IMPLEMENTATION.md: Technical documentation - app/controllers/benchmark_controller.rb: Performance testing endpoints - ext/widget_renderer/: Complete Rust extension source code - ext/widget_renderer/widget_renderer.so: Compiled binary (x86-64) - ext/widget_renderer/widget-uswds-bundle.js: Embedded USWDS bundle Files Modified: - app/controllers/touchpoints_controller.rb: Use form.touchpoints_js_string - app/models/form.rb: Add Rust/ERB fallback logic (no Ruby method changes) - config/routes.rb: Add benchmark routes - ext/widget_renderer/src/form_data.rs: Compute prefix from load_css - ext/widget_renderer/src/template_renderer.rs: USWDS bundle embedding
- Remove skip_before_action :verify_authenticity_token - Add before_action to ensure development environment only - Benchmark endpoints now properly protected and restricted to development mode - Addresses CodeQL security alert #41
Co-authored-by: Copilot <[email protected]> Signed-off-by: Riley Seaburg <[email protected]>
- Added widget_erb_benchmark endpoint to benchmark ERB in controller context - ERB can be tested with Rails helpers available (not in complete isolation) - Updated benchmark results with direct render comparison Direct Render Results: - Rust: 2.658ms avg (376.19 renders/s) - ERB: 34.387ms avg (29.08 renders/s) - Performance: 12.9x faster with Rust HTTP Request Results (unchanged): - Rust: 58.45ms avg (17.11 req/s) - ERB: 707.9ms avg (1.41 req/s) - Performance: 12.1x faster with Rust
Changed raw string literal delimiters from r#"..."# to r###"..."### to avoid conflicts with JavaScript code containing "# sequences. This fixes all compilation errors related to unterminated strings and unknown character escapes in regex patterns.
When ASSET_HOST differs from the page origin, SRI (Subresource Integrity) checks require CORS headers on the asset responses. This adds Access-Control-Allow-Origin headers to the public file server configuration for both staging and production environments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request extends the permitted parameters in the
form_paramsmethod of theAdmin::FormsControllerto support additional question fields. This change allows the controller to handle up to 30 question text inputs in forms, increasing flexibility for larger forms.Form parameter extension:
:question_text_21through:question_text_30in theform_paramsmethod inapp/controllers/admin/forms_controller.rb, allowing forms to include up to 30 questions.