Skip to content
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.

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

JNG-5833 ui operations #286

Merged
merged 8 commits into from
Jan 31, 2025
Merged

JNG-5833 ui operations #286

merged 8 commits into from
Jan 31, 2025

Conversation

noherczeg
Copy link
Contributor

Will be extended later.

Copy link

coderabbitai bot commented Jan 31, 2025

Warning

Rate limit exceeded

@noherczeg has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 13 minutes and 34 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 3f254ad and 31c6ea9.

📒 Files selected for processing (2)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/structure/transferActionDeclaration.etl (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/viewActionDeclaration.etl (1 hunks)

Walkthrough

The pull request introduces comprehensive enhancements to the Judo Tatami JSL-to-UI transformation framework. The changes primarily focus on expanding the capabilities of action declarations, introducing new methods for handling transfer actions, view actions, and UI elements. Multiple Epsilon transformation and operation files have been modified to support more dynamic and flexible action handling across different UI components, including views, tables, groups, and tabs. A new test class has also been added to validate these new operations and transformations.

Changes

File Change Summary
.../data/_importData.eol Added import for transferActionDeclaration.eol
.../data/transferActionDeclaration.eol Added multiple methods for TransferActionDeclaration, including getId(), getFqName(), isStatic(), etc.
.../data/transferDeclaration.eol Added methods getAllActions(), hasSortableField(), hasFilterableField()
.../ui/rowDeclaration.eol Added getAllActionDeclarations() method
.../ui/viewActionDeclaration.eol Renamed methods, added new action-related methods like isCallAction(), hasOutput()
.../ui/viewDeclaration.eol Added getAllActionDeclarations() method
.../ui/viewGroupDeclaration.eol Added getAllActionDeclarations() method
.../ui/viewTableDeclaration.eol Added getAllActionDeclarations() method
.../ui/viewTabsDeclaration.eol Added getAllActionDeclarations() method
.../transformations/ui/jslToUi.etl Added two new import statements for transfer and view action declarations
.../transformations/ui/modules/structure/transferActionDeclaration.etl Added multiple transformation rules for transfer actions
.../transformations/ui/modules/view/menuTableDeclarationViewPage.etl Added loop to process action declarations
.../transformations/ui/modules/view/viewActionDeclaration.etl Added numerous transformation rules for view actions
.../test/java/.../JslModel2UiOperationsTest.java New test class with methods to validate operations on views

Poem

🐰 Hop, skip, and a transformation leap,
Actions dancing, no detail too deep!
From JSL to UI, we weave our spell,
Declarations singing their stories well 🎉
Code rabbits rejoice, our framework's complete! 🚀


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

‼️ IMPORTANT
Auto-reply has been disabled for this repository in the CodeRabbit settings. The CodeRabbit bot will not respond to your replies unless it is explicitly tagged.

  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (13)
judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/structure/transferActionDeclaration.etl (2)

1-30: Consider handling an additional else scenario for operationType.
If self.eContainer.map is not defined, operationType remains unset. You may want to set a default type or throw an error to avoid unexpected null references.


67-84: Potential spelling issue in property name.
The property is spelled paramaterName, which might be a typo. Consider renaming the property to parameterName if it aligns with your domain.

- t.name = s.paramaterName;
+ t.name = s.parameterName;
judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/viewActionDeclaration.etl (2)

1-41: Avoid overwriting the dataElement assignment.
You assign t.dataElement = s.equivalent("OperationType") at line 20, then reassign it to s.transferAction.target.equivalent("OperationType") at line 36. Unless both references are guaranteed identical, consider removing or clarifying the first assignment to avoid confusion.

- t.dataElement = s.equivalent("OperationType");
  ...
  ...
  t.dataElement = s.transferAction.target.equivalent("OperationType");

66-75: Review commented-out assignment of targetType.
The commented-out logic at line 72 may be needed for some scenarios. Verify whether this is intentionally left out or should be restored.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewTabsDeclaration.eol (1)

49-53: Consider documenting the reason for commented-out code.

The commented-out code for handling UIViewLinkDeclaration suggests potential future functionality. If this is intended for future implementation, consider adding a TODO comment explaining why it's commented out and when it should be uncommented.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewGroupDeclaration.eol (1)

57-80: Consider documenting the reason for commented-out code.

Similar to viewTabsDeclaration.eol, there's commented-out code for UIViewLinkDeclaration. Consider adding a TODO comment if this is intended for future implementation.

judo-tatami-jsl-jsl2ui/src/test/java/hu/blackbelt/judo/tatami/jsl/jsl2ui/application/JslModel2UiOperationsTest.java (7)

266-376: Consider extracting helper methods for better readability.

While the test is thorough, it could benefit from helper methods to encapsulate common assertion patterns and improve readability.

Consider extracting helper methods for common patterns:

+    private void assertOperationParameters(OperationType operation, String expectedInputFQName, String expectedOutputFQName) {
+        OperationParameterType input = operation.getInput();
+        OperationParameterType output = operation.getOutput();
+        
+        assertEquals(expectedInputFQName, input.getFQName());
+        assertEquals(expectedOutputFQName, output.getFQName());
+    }
+
+    private void assertTableButtons(Table table, List<String> expectedTableButtons, List<String> expectedRowButtons) {
+        List<Button> tableButtons = table.getTableActionButtonGroup().getButtons();
+        List<Button> rowButtons = table.getRowActionButtonGroup().getButtons();
+        
+        assertEquals(expectedTableButtons, tableButtons.stream().map(NamedElement::getFQName).sorted().toList());
+        assertEquals(expectedRowButtons, rowButtons.stream().map(NamedElement::getFQName).sorted().toList());
+    }

378-430: Consider extracting helper methods for better readability.

Similar to the previous test, this method could benefit from helper methods to encapsulate common assertion patterns.

Consider extracting helper methods for common patterns:

+    private void assertPageActions(PageDefinition page, List<String> expectedActionFQNames) {
+        List<Action> actions = page.getActions();
+        assertEquals(expectedActionFQNames, actions.stream().map(NamedElement::getFQName).sorted().toList());
+    }
+
+    private void assertCallOperationAction(Action action, OperationType expectedOperation, PageDefinition expectedPage) {
+        assertEquals(expectedOperation, action.getTargetDataElement());
+        assertEquals(expectedPage, action.getTargetPageDefinition());
+    }

129-230: Consider improving test organization and readability.

The test is comprehensive but could benefit from:

  1. Moving test data setup to a separate method.
  2. Grouping assertions into logical sections with descriptive comments.

Example refactor:

+    private void assertDataElements(Application application) {
+        assertEquals(List.of(
+            "A::OperationsOnViews::A",
+            "A::OperationsOnViews::Error1",
+            "A::OperationsOnViews::ErrorWithDefaults",
+            "A::OperationsOnViews::Transfer1",
+            "A::OperationsOnViews::Transfer2",
+            "A::OperationsOnViews::TransferX"
+        ), application.getDataElements().stream().map(NamedElement::getFQName).sorted().toList());
+    }
+
     @Test
     void testOperationsOnViews() throws Exception {
-        jslModel = JslParser.getModelFromStrings("OperationsOnViews", List.of(createModelString("OperationsOnViews")));
+        // Setup
+        setupTestModel("OperationsOnViews");
         
-        transform();
+        // When
+        Application application = transformAndGetApplication();
         
-        List<Application> apps = uiModelWrapper.getStreamOfUiApplication().toList();
-        assertEquals(1, apps.size());
-        Application application = apps.get(0);
-
-        assertEquals(List.of(
-            "A::OperationsOnViews::A",
-            // ...
-        ), application.getDataElements().stream().map(NamedElement::getFQName).sorted().toList());
+        // Then
+        assertDataElements(application);
         // ... rest of the assertions
     }

232-264: Add descriptive messages to assertions.

The test would be more maintainable with descriptive messages in assertions to help identify failures.

Example refactor:

-        assertNull(myAction1.getInput());
-        assertNull(myAction1.getOutput());
+        assertNull(myAction1.getInput(), "Parameterless operation should not have input");
+        assertNull(myAction1.getOutput(), "Void operation should not have output");

266-376: Extract helper methods for common operations.

The test has repeated code for finding elements by FQName. Consider extracting these into helper methods.

Example refactor:

+    private <T extends NamedElement> T findByFQName(List<T> elements, String fqName) {
+        return elements.stream()
+            .filter(e -> e.getFQName().equals(fqName))
+            .findFirst()
+            .orElseThrow(() -> new AssertionError("Element not found: " + fqName));
+    }
+
     @Test
     void testOperationsOnViewsWithInputSelectors() throws Exception {
         // ... setup code ...
-        ClassType transferX = classTypes.stream()
-            .filter(c -> c.getFQName().equals("A::OperationsOnViewsWithInputSelectors::TransferX"))
-            .findFirst().orElseThrow();
+        ClassType transferX = findByFQName(classTypes, "A::OperationsOnViewsWithInputSelectors::TransferX");

378-430: Consider using test data builders.

The test could benefit from using test data builders to make the test setup more maintainable and readable.

Example refactor:

+    private static class TestModelBuilder {
+        private final StringBuilder model = new StringBuilder();
+        
+        public TestModelBuilder withEntity(String name) {
+            model.append("entity ").append(name).append(" {\n");
+            return this;
+        }
+        
+        public String build() {
+            return model.toString();
+        }
+    }
+
     @Test
     void testOperationsOnViewsWithInputForms() throws Exception {
-        jslModel = JslParser.getModelFromStrings("OperationsOnViewsWithInputForms", 
-            List.of(createModelString("OperationsOnViewsWithInputForms")));
+        jslModel = JslParser.getModelFromStrings("OperationsOnViewsWithInputForms",
+            List.of(new TestModelBuilder()
+                .withEntity("Entity1")
+                // ... configure test data ...
+                .build()));

129-230: Consider adding test cases for error scenarios.

The test thoroughly validates the happy path but could benefit from additional test cases:

  • Invalid model configurations
  • Missing required elements
  • Edge cases in operation definitions
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 68110f2 and ee96b50.

📒 Files selected for processing (14)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/data/_importData.eol (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/data/transferActionDeclaration.eol (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/data/transferDeclaration.eol (4 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/rowDeclaration.eol (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewActionDeclaration.eol (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewDeclaration.eol (3 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewGroupDeclaration.eol (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewTableDeclaration.eol (2 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewTabsDeclaration.eol (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/jslToUi.etl (2 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/structure/transferActionDeclaration.etl (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/menuTableDeclarationViewPage.etl (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/viewActionDeclaration.etl (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/test/java/hu/blackbelt/judo/tatami/jsl/jsl2ui/application/JslModel2UiOperationsTest.java (1 hunks)
👮 Files not reviewed due to content moderation or server errors (3)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/data/transferDeclaration.eol
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/menuTableDeclarationViewPage.etl
  • judo-tatami-jsl-jsl2ui/src/test/java/hu/blackbelt/judo/tatami/jsl/jsl2ui/application/JslModel2UiOperationsTest.java
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: ⏳ Build, test and deploy artifacts
🔇 Additional comments (33)
judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/structure/transferActionDeclaration.etl (3)

32-41: No issues found.
This rule correctly extends the abstract rule and sets the ID and adds the operation to the corresponding class type.


43-65: No issues found.
The transformation logic for output parameters appears consistent with the domain (refresh, update, delete behaviors).


86-98: No issues found.
The transformation for error declarations into fault parameters looks correct.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/data/_importData.eol (1)

7-7: Import statement looks valid.
No circular dependencies are apparent. The new import should allow referencing additional operations from transferActionDeclaration.eol.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/rowDeclaration.eol (2)

21-24: LGTM! Good use of recursion for collecting visual elements.

The implementation correctly collects action declarations and their nested visual elements.


29-34: LGTM! Good use of caching for performance optimization.

The implementation efficiently collects action declarations using a cached operation.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewActionDeclaration.eol (3)

2-9: LGTM! Consistent naming convention.

The renaming from ViewActionDeclaration to UIActionDeclaration aligns with the framework's naming patterns.


11-35: LGTM! Clear and specific action type checks.

The implementation provides well-defined checks for different action types with appropriate caching.


37-56: LGTM! Comprehensive visual elements collection.

The implementation handles all cases (form, selector table, return) correctly and uses recursion appropriately.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/data/transferActionDeclaration.eol (1)

1-54: LGTM! Comprehensive transfer action operations.

The implementation provides well-structured operations with appropriate caching and edge case handling.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewTableDeclaration.eol (2)

40-43: LGTM! Consistent with rowDeclaration implementation.

The implementation follows the same pattern as in rowDeclaration.eol for collecting action declarations.


63-70: LGTM! Consistent with rowDeclaration implementation.

The implementation follows the same pattern as in rowDeclaration.eol for collecting action declarations.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewTabsDeclaration.eol (1)

46-69: LGTM! Well-structured implementation with performance optimization.

The implementation follows the same pattern as getExposedVisualElements() and uses @cached appropriately for performance optimization. The method effectively aggregates action declarations from all relevant UI components.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewGroupDeclaration.eol (1)

47-50: LGTM! Good addition to exposed visual elements.

The addition of action declarations to getExposedVisualElements() maintains consistency with the UI component hierarchy.

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/ui/viewDeclaration.eol (2)

42-44: LGTM! Good addition to handle nested action declarations.

The addition ensures that exposed visual elements from nested action declarations are properly included.


99-114: LGTM! Well-implemented with deterministic ordering.

The implementation effectively collects action declarations and provides a deterministic order by sorting. The return type of List (vs Set in other similar methods) is appropriate here due to the sorting requirement.

judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/jslToUi.etl (1)

7-7: LGTM! Appropriate imports for action handling.

The addition of transferActionDeclaration.etl and viewActionDeclaration.etl imports aligns with the enhanced action declaration handling implemented in other files.

Also applies to: 27-27

judo-tatami-jsl-jsl2ui/src/main/epsilon/operations/jsl/data/transferDeclaration.eol (8)

79-82: LGTM!

The function is well-optimized with @cached decorator and correctly filters members by type.


214-217: LGTM!

The function is well-optimized with @cached decorator and correctly checks for sortable fields.


219-222: LGTM!

The function is well-optimized with @cached decorator and correctly checks for filterable fields.


15-15: LGTM! The changes correctly handle action-related transfer objects.

The function now properly includes transfer objects from actions, ensuring that error types, parameter types, and return types are correctly exposed.

Also applies to: 27-35


79-82: LGTM! The function follows the established pattern.

The implementation is clean, efficient (using @cached), and follows the same pattern as other similar functions in the file.


15-15: LGTM! The changes correctly handle action-related transfer objects.

The function now properly collects transfer objects from action errors, parameter types, and return types, following the same pattern used for relations.

Also applies to: 27-35


79-82: LGTM! The function follows the established pattern.

The function is correctly cached and follows the same pattern as other member retrieval functions in the file.


214-222: LGTM! The functions correctly check for field properties.

Both functions are properly cached and follow the same pattern for checking field properties.

judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/menuTableDeclarationViewPage.etl (3)

72-77: Address the TODO comment for tabular reference field actions.

The code correctly processes action declarations, but there's a TODO comment indicating that additional logic is needed for tabular reference field actions.

Would you like me to help implement the if-else conditions for tabular reference field actions? This would ensure proper handling of actions based on their context.


72-77: Address the TODO comment for tabular reference field actions.

The implementation correctly adds view actions, but there's a TODO comment indicating that additional logic is needed for tabular reference field actions.

Would you like me to help implement the if-else conditions for tabular reference field actions? This would ensure proper handling of actions based on their context.


72-77: Address the TODO comment for tabular reference field actions.

The action handling logic is correct, but there's a TODO comment indicating that additional logic is needed for tabular reference field actions.

Do you want me to help implement the if-else conditions for tabular reference field actions?

judo-tatami-jsl-jsl2ui/src/test/java/hu/blackbelt/judo/tatami/jsl/jsl2ui/application/JslModel2UiOperationsTest.java (5)

129-230: LGTM!

The test method provides comprehensive coverage of basic operations on views with well-structured assertions.


232-264: LGTM!

The test method effectively validates parameterless void operations and their fault types.


232-264: LGTM! The test effectively validates parameterless void operations.

The test provides good coverage of input, output, and fault parameters for parameterless void operations.


266-376: LGTM! The test provides comprehensive coverage of input selector operations.

The test thoroughly validates all aspects of operations with input selectors, including UI elements, actions, and relationships.


378-430: LGTM! The test effectively validates input form operations.

The test provides thorough coverage of operations with input forms, including form structure, actions, and relationships.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

♻️ Duplicate comments (2)
judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/viewActionDeclaration.etl (2)

146-160: ⚠️ Potential issue

Remove duplicate rule "OperationInputFormCallAction".

The rule appears twice in the file with similar logic. This duplication can lead to unexpected behavior during transformation.

Keep only one instance of the rule and update all references to use the single implementation. Consider keeping the second instance (lines 309-323) as it has additional logic for handling target data elements.

-@lazy
-rule OperationInputFormCallAction
-    transform s: JSL!UIActionDeclaration
-    to t: UI!ui::Action {
-        t.setId(rootMenu.name + "/(jsl/" + s.getId() + ")/OperationInputFormCallAction");
-        t.name = s.name + "::CallOperation";
-        t.ownerDataElement = s.transferAction.target.equivalent("OperationType");
-        t.actionDefinition = s.equivalent("OperationInputFormCallActionDefinition");
-        if (s.hasOutput()) {
-            t.targetPageDefinition = s.equivalent("OperationOutputPageDefinition");
-        }
-
-        log.debug("OperationInputFormCallAction: " + t.name);
-}

Also applies to: 309-323


359-361: ⚠️ Potential issue

Fix undefined variable "op" in condition.

The variable op is undefined and should be uiOp based on the context.

Apply this fix:

-                if (op?.input?.target == ad?.getOperationReference()?.getMember()?.input?.target) {
+                if (uiOp?.input?.target == ad?.getOperationReference()?.getMember()?.input?.target) {
🧹 Nitpick comments (2)
judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/viewActionDeclaration.etl (2)

1-41: Consider adding input validation for button properties.

The ViewActionDeclarationButton rule should validate the input parameters before transformation.

Add validation for:

  • Undefined or empty name
  • Invalid icon format
  • Missing or invalid action definition
 rule ViewActionDeclarationButton
     transform s: JSL!UIActionDeclaration
     to t: UI!ui::Button {
         guard: rootMenu.containsVisualElement(s)
+        
+        if (s.name.isUndefined() or s.name.trim().isEmpty()) {
+            throw "Button name cannot be empty for " + s.getId();
+        }
 
         t.setId(rootMenu.name + "/(jsl/" + s.getId() + ")/ViewActionDeclarationButton");

1-435: Consider organizing rules into logical groups.

The file contains many related rules that could be organized better for maintainability.

Consider grouping rules into categories using comments:

  • Button-related rules
  • Action definition rules
  • Page definition rules
  • Operation-specific rules

Example:

+// ============================================
+// Button-related transformation rules
+// ============================================
 rule ViewActionDeclarationButton
     transform s: JSL!UIActionDeclaration
     to t: UI!ui::Button {
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ee96b50 and 3f254ad.

📒 Files selected for processing (2)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/structure/transferActionDeclaration.etl (1 hunks)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/view/viewActionDeclaration.etl (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • judo-tatami-jsl-jsl2ui/src/main/epsilon/transformations/ui/modules/structure/transferActionDeclaration.etl
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: ⏳ Build, test and deploy artifacts

@noherczeg noherczeg merged commit dc9863f into develop Jan 31, 2025
3 checks passed
@noherczeg noherczeg deleted the feature/JNG-5833-ui-operations branch January 31, 2025 12:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants