Conversation
…f overloaded setters and add comprehensive unit tests
There was a problem hiding this comment.
Pull request overview
This PR contains version bump from 26.2.2 to 26.2.3 along with several minor fixes and improvements to the Dynamia Tools framework. The changes include bug fixes for handling overloaded setters in reflection utilities, UI improvements for charts and dashboards, a Spanish translation correction, and enhanced documentation with comprehensive test coverage.
Changes:
- Version bump across all modules from 26.2.2 to 26.2.3
- Enhanced PropertyAccessor with improved overloaded setter handling and comprehensive test coverage
- Fixed chart container reference bug in ReportViewer (West → East)
- Updated CSS classes in DashboardViewRenderer from custom
dt-*classes to standard Bootstrapcol-*classes - Added new "Dynamia" color palette for charts
- Corrected Spanish translation typo ("generanci" → "generando")
Reviewed changes
Copilot reviewed 55 out of 55 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
| pom.xml (multiple) | Version bump from 26.2.2 to 26.2.3 across all framework modules |
| PropertyAccessor.java | Added comprehensive overloaded setter handling with fallback strategies and extensive documentation |
| PropertyAccessorTest.java | New test file with comprehensive coverage for overloaded setter scenarios |
| BeanTransformer.java | Refactored setupBean to use BeanWrapper batch operations for better performance |
| RequiredFieldCustomizer.java | Changed input attributes from String to Map for proper structure |
| EntityPickerBox.java | Added setEntityClassName alias method for better API compatibility |
| ReportViewer.java | Fixed layout.getWest() → layout.getEast() bug and added color palette support |
| DashboardViewRenderer.java | Updated CSS classes from dt-col/dt-row to standard Bootstrap col/row |
| ChartjsDashboardWidget.java | Added new "Dynamia" color palette with 20 modern colors |
| Messages_es.properties | Fixed spelling error in Spanish translation |
| * <p> | ||
| * Example: | ||
| * <pre>{@code | ||
| * Person person = new Person(); | ||
| * PropertyAccessor.setFieldValue("name", person, "John"); | ||
| * // person.name = "John" | ||
| * }</pre> |
There was a problem hiding this comment.
The Javadoc formatting is inconsistent. The <p> tag should be placed after @param declarations but before the Example: section, not as part of the @param description. This makes the documentation harder to read and may cause issues with Javadoc generation tools.
Update the formatting to match the pattern used elsewhere in the codebase (see lines 88-98 for the correct pattern).
| * <p> | ||
| * Example: | ||
| * <pre>{@code | ||
| * Customer customer = new Customer(); | ||
| * // Invoke setter | ||
| * PropertyAccessor.invokeMethod(customer, "setName", "John Doe"); | ||
| * // Invoke getter | ||
| * String name = (String) PropertyAccessor.invokeMethod(customer, "getName"); | ||
| * // Invoke business method | ||
| * PropertyAccessor.invokeMethod(customer, "sendWelcomeEmail", "john@example.com"); | ||
| * }</pre> |
There was a problem hiding this comment.
The Javadoc formatting is inconsistent. The <p> tag should be placed after @param declarations but before the Example: section, not as part of the @param description. This makes the documentation harder to read and may cause issues with Javadoc generation tools.
Update the formatting to match the pattern used elsewhere in the codebase (see lines 88-98 for the correct pattern).
| * <p> | ||
| * Example: | ||
| * <pre>{@code | ||
| * Person person = new Person(); | ||
| * PropertyAccessor.invokeSetMethod(person, "name", "John"); | ||
| * PropertyAccessor.invokeSetMethod(person, "age", 30); | ||
| * | ||
| * Example: | ||
| * <pre>{@code | ||
| * Person person = new Person(); | ||
| * PropertyAccessor.invokeSetMethod(person, "name", "John"); | ||
| * PropertyAccessor.invokeSetMethod(person, "age", 30); | ||
| * // Nested property | ||
| * PropertyAccessor.invokeSetMethod(person, "address.city", "New York"); | ||
| * | ||
| * // Nested property | ||
| * PropertyAccessor.invokeSetMethod(person, "address.city", "New York"); | ||
| * }</pre> | ||
| * // Overloaded setters - automatically selects correct method | ||
| * PropertyAccessor.invokeSetMethod(person, "address", new Address(...)); | ||
| * }</pre> |
There was a problem hiding this comment.
The Javadoc formatting is inconsistent. The <p> tag should be placed after @param declarations but before the Example: section, not as part of the @param description. This makes the documentation harder to read and may cause issues with Javadoc generation tools.
Update the formatting to match the pattern used elsewhere in the codebase (see lines 88-98 for the correct pattern).
| * <p> | ||
| * Example: | ||
| * <pre>{@code | ||
| * PropertyInfo prop = ObjectOperations.getPropertyInfo(Person.class, "name"); | ||
| * PropertyAccessor.invokeSetMethod(person, prop, "John"); | ||
| * }</pre> |
There was a problem hiding this comment.
The Javadoc formatting is inconsistent. The <p> tag should be placed after @param declarations but before the Example: section, not as part of the @param description. This makes the documentation harder to read and may cause issues with Javadoc generation tools.
Update the formatting to match the pattern used elsewhere in the codebase (see lines 88-98 for the correct pattern).
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
There was a problem hiding this comment.
The file contains excessive trailing blank lines (lines 256-264). According to clean code practices and the coding guideline to keep code clean and maintainable, source files should not have more than one or two blank lines at the end.
Remove the extra blank lines, leaving at most 1-2 blank lines at the end of the file.
| * <p> | ||
| * Example: | ||
| * <pre>{@code | ||
| * Person person = new Person(); | ||
| * | ||
| * // Setup from map | ||
| * Map<String, Object> values = new HashMap<>(); | ||
| * values.put("name", "John Doe"); | ||
| * values.put("age", 30); | ||
| * values.put("email", "john@example.com"); | ||
| * BeanTransformer.setupBean(person, values); | ||
| * | ||
| * // Setup from request parameters | ||
| * @PostMapping("/users") | ||
| * public void createUser(@RequestBody Map<String, Object> data) { | ||
| * User user = new User(); | ||
| * BeanTransformer.setupBean(user, data); | ||
| * userRepository.save(user); | ||
| * } | ||
| * | ||
| * // Supports nested properties (dot notation) | ||
| * Map<String, Object> data = Map.of( | ||
| * "name", "John", | ||
| * "address.city", "New York", | ||
| * "address.zipCode", "10001" | ||
| * ); | ||
| * BeanTransformer.setupBean(person, data); | ||
| * }</pre> |
There was a problem hiding this comment.
The Javadoc formatting is inconsistent. The <p> tag and Example section should be placed after the @param declarations, not embedded within them. This unusual indentation and placement makes the documentation harder to read and may cause issues with Javadoc generation tools.
Update the formatting to match the pattern used elsewhere in the codebase where the <p> tag comes after all @param declarations.
| * <p> | ||
| * Example: | ||
| * <pre>{@code | ||
| * Person person = new Person(); | ||
| * | ||
| * // Merge from multiple sources | ||
| * PersonBasicDTO basic = getBasicInfo(); | ||
| * PersonContactDTO contact = getContactInfo(); | ||
| * PersonPreferencesDTO prefs = getPreferences(); | ||
| * | ||
| * BeanTransformer.merge(person, basic, contact, prefs); | ||
| * // person now has properties from all three DTOs | ||
| * | ||
| * // Build object from multiple partial sources | ||
| * User user = new User(); | ||
| * BeanTransformer.merge(user, | ||
| * userProfile, | ||
| * userSettings, | ||
| * userPermissions | ||
| * ); | ||
| * }</pre> |
There was a problem hiding this comment.
The Javadoc formatting is inconsistent. The <p> tag and Example section should be placed after the @param declarations, not embedded within them. This unusual indentation and placement makes the documentation harder to read and may cause issues with Javadoc generation tools.
Update the formatting to match the pattern used elsewhere in the codebase where the <p> tag comes after all @param declarations.
| * <p> | ||
| * Example: | ||
| * <pre>{@code | ||
| * PropertyInfo prop = ObjectOperations.getPropertyInfo(Person.class, "name"); | ||
| * PropertyAccessor.setFieldValue(prop, person, "John"); | ||
| * }</pre> |
There was a problem hiding this comment.
The Javadoc formatting is inconsistent. The <p> tag should be placed after @param declarations but before the Example: section, not as part of the @param description. This makes the documentation harder to read and may cause issues with Javadoc generation tools.
Update the formatting to match the pattern used elsewhere in the codebase (see lines 88-98 of the same file for the correct pattern).
| * <p> | ||
| * Example: | ||
| * <pre>{@code | ||
| * // Copy from another bean | ||
| * Person person = new Person(); | ||
| * PersonDTO dto = getPersonDTO(); | ||
| * BeanTransformer.setupBean(person, dto); | ||
| * | ||
| * // Copy from map | ||
| * Person person = new Person(); | ||
| * Map<String, Object> data = getPersonData(); | ||
| * BeanTransformer.setupBean(person, data); | ||
| * | ||
| * // Update existing entity from DTO | ||
| * Person existingPerson = personRepository.findById(id); | ||
| * PersonUpdateDTO updateData = getUpdateData(); | ||
| * BeanTransformer.setupBean(existingPerson, updateData); | ||
| * personRepository.save(existingPerson); | ||
| * }</pre> |
There was a problem hiding this comment.
The Javadoc formatting is inconsistent. The <p> tag and Example section should be placed after the @param declarations, not embedded within them. This unusual indentation and placement makes the documentation harder to read and may cause issues with Javadoc generation tools.
Update the formatting to match the pattern used elsewhere in the codebase where the <p> tag comes after all @param declarations.
| chart.setData(data); | ||
| chart.setTitle(c.getTitle()); | ||
|
|
||
|
|
There was a problem hiding this comment.
Extra blank line that should be removed for code consistency and cleanliness. The codebase convention is to avoid multiple consecutive blank lines within methods.
No description provided.