Issue #2755 - Date editor: prevent hidden time-portion in @DateOnly properties#2757
Open
jhou-pro wants to merge 41 commits into
Open
Issue #2755 - Date editor: prevent hidden time-portion in @DateOnly properties#2757jhou-pro wants to merge 41 commits into
@DateOnly properties#2757jhou-pro wants to merge 41 commits into
Conversation
…ates on calendar.
…nts to allday cell on top of the fullcalendar. Also implemented logic that rebuilds dataset for fullcalendar when switching between daygrid view to time grid view.
This applies to all kinds of properties: 1. Fixed time-zone properties (only UTC). 2. Simple properties of whatever kinds (including @DependentTimeZoneMode ones).
…z(prop)` in date-picker components. The four call sites that build a fresh "now" moment — the default date in `tg-calendar`, the highlighted today and the fallback month in `tg-month-selector`, and the auto-inserted current year in tg-datetime-picker` — now use `now(prop)`. Unlike `_momentTz(prop)`, which returns the current instant in the surrogate (server) time-zone, `now(prop)` re-resolves it in the user's real time-zone under independent time-zone mode, and applies `@DateOnly` trimming and the `@DependentTimeZoneMode` override consistently, so these defaults stay correct across time-zone and date boundaries. The `_momentTz` calls that convert an explicit value (a selected date, year/month/day objects, parsed strings or an entity value) are intentionally left unchanged, since they are not "now" creators.
…millis without time portion.
The cache was causing a memory leak, as described in the issue.
Issue #2750 - `tg-fullcalendar`: locale-aware date format, all-day segments for multi-day events, view-aware rendering
Issue #2765 - Memory leak in EQL due to SQL type name caching issue
… shaken source changes - zero impact).
…rosemirror-*` transitive dependencies.
…ependencies (including `js-yaml` 4.1.1 => 4.2.0).
Please note that https://github.com/fieldenms/tg/security/dependabot/364 still have no patched version (Low severity).
Issue #2768 - Update Rich Text editor dependencies: `dompurify` and `prosemirror`
…tity-instances Program instructions: Fixed Entity Instances
…speed of rendering of EGI.
…ched calendar mutations into a single re-render. The event source rebuild ran on every centre run even while the calendar was a hidden alternative view (display:none inside iron-pages), and FullCalendar re-renders synchronously after every single mutation: - clearing the previous run’s events dispatched one remove per event; - each entity added up to three event segments (timed + all-day splitting from #2750), each triggering its own re-render; - gotoDate was invoked inside the entity loop, dispatching up to once per entity; - a trailing render() forced one more full render plus updateSize. For ~300 entities this meant 1000+ synchronous re-renders per run, all wasted while the calendar was not visible — the dominant contributor to the centre slowdown reported in #2780. Changes: - _updateEventSource now skips the rebuild while the calendar is hidden (offsetParent === null), raising a pending flag instead; _resizeEventListener flushes the pending rebuild upon the iron-resize event that accompanies becoming visible (iron-pages performs notifyResize on every selection change, and the calendar already relies on that same event for layout recovery after being shown). - The rebuild moved into _rebuildEventSource with all mutations wrapped in Calendar::batchRendering, so exactly one re-render happens when the batch completes. - removeAllEvents() replaces per-event remove() — a single dispatch instead of one per previous event. - gotoDate is hoisted out of the entity loop and executed once, after the earliest event start across all entities is known. - Redundant trailing render() calls removed — the batch resume performs the single render; iron-resize still triggers render() for genuine resizes and on show. - Entities without a start date no longer poison startTime (previously Infinity > null coerced startTime to null, silently disabling navigate-to-first-event for the whole run). The per-entity event splitting logic is unchanged. Subclasses that override only tooltip logic (e.g. tg-work-activity-calendar in TTGAMS) inherit the optimisation as-is.
…nd cell tooltips, batched run data assignment. Three client-side costs scaled poorly with result set size on every centre run: - hasAction and cell tooltip bindings called findEntityIndex per cell — a linear scan over entities, making rendering cost quadratic in the number of rows (~1.8M entity comparisons for 300 rows x 20 columns); - tooltip HTML was computed eagerly for every stamped cell, while TgTooltipBehavior reads the tooltip-text attribute only at hover time; - _setPageData pushed run data in five sequential passes: entities first (triggering an egiModel rebuild that read stale rendering hints and action indices), then per-array observers walked all rows performing a per-row set against instances about to be replaced. Changes: - findEntityIndex now resolves through memoised identity / id maps, invalidated on each entities assignment; inputs that miss both maps fall back to the original linear scan. - Body cell tooltips are computed on demand by _provideCellTooltip (delegated mouseover / touchstart on the scroll container) instead of eager tooltip-text$ bindings in the row templates; stale attributes are dropped on model rebuild; totals cells keep their eager _getTotalTooltip binding. - New EGI primeGridData assigns rendering hints and action indices ahead of the entities assignment with per-row refresh suppressed; _setPageData primes first, so the single egiModel rebuild consumes fresh values in one pass and the redundant per-row refresh passes are gone. Public signatures (hasAction, findEntityIndex, _getTooltip) are unchanged — external callers such as tg-gis-component are unaffected.
…tion during DOM stamping, dismissal of stale cell tooltips, cheaper tooltip cleanup and entity index maps.
Correctness:
- Cell tooltips are provisioned on mousemove in addition to mouseover / touchstart, covering a pointer already resting inside a cell whose tooltip was invalidated — mouseover fires only on boundary crossings.
- The egiModel rebuild, updateEntity and _updateColumns invalidate the hovered cell’s tooltip and dismiss the displayed / pending tooltip via hideTooltip.
Refreshing the tooltip-text attribute alone could not prevent stale content: tg-tooltip.show is a no-op while a tooltip is already displayed (its content is frozen) and a pending show timer captures the text at trigger time.
The dismissal is guarded by a :hover check on the invalidated cell, leaving unrelated tooltips alone.
Efficiency and maintainability:
- Model rebuilds clear tooltip-text attributes via the small set of cells that actually received one, instead of a querySelectorAll scan over all stamped cells.
- The byId entity index map is built lazily upon the first byRef miss — the dominant rendering path (same references) never needs it; id extraction is shared between the map builder and findEntityIndex via entityIdOf, mirroring _areEqual’s id-first rule.
…ilds deferred while hidden. A rebuild deferred while the calendar was hidden evaluated dataChangeReason only at flush time, so a refresh arriving before the flush (e.g. save-and-refresh or SSE while the grid view was selected) cancelled the navigation owed to an earlier run — the calendar then opened on the current date with all events outside the visible range. The navigation intent is now latched when deferring (any non-refresh update while hidden owes a navigation) and consumed by the flush, which no longer consults dataChangeReason. A rebuild on the visible path supersedes any deferred one: it clears the pending flag and honours an owed latched navigation, closing the small window where entities arrive after the view becomes visible but before the iron-resize flush. Visible run / refresh behaviour and view-type switching retain their previous semantics.
Issue #2780 - Entity Centre rendering optimisations: EGI cell overflow button and hidden tg-fullcalendar rebuild
Issue #2777 - jackson-databind update from 2.21.1 to 2.22.0
#2777 Updated Jackson to 2.22.1.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Resolve #2755
To be completed by the pull request creator
This section should be completed with reference to section Preparing PR of the Code and PR reviews wiki page.
Create the pull request as a draft by tapping the dropdown arrow on the 'Create pull request' button under the pull request description (below the text box where this description is being edited) and changing the default
Create pull requesttoDraft pull request.Or, if the pull request has already been created, convert it to draft by tapping the "Convert to draft" link beneath the "Reviewers" section.
A self-review of all changes has been completed, and the changes are in sync with the issue requirements.
Changes to the requirements have been reflected in the issue description.
Any "leftovers" such as sysouts, printing of stack traces, and any other "temporary" code, have been removed.
Developer documentation (e.g., comments, Javadoc), have been provided where required.
All existing and new Java tests pass successfully by running them with Maven.
New Web tests have been written or existing tests adjusted, if required, to cover the new functionality.
All existing and new Web tests pass successfully.
Changes have been inspected for possible NPE situations, and the changes are sufficiently defensive.
The correct base branch has been selected for these changes to be merged into.
The latest changes from the base branch have already been merged into this feature branch (and tested).
Added a change overview to the issue description or as a wiki page, referenced in the issue description.
Some issues might be very descriptive and serve in place of a wiki page.
In such cases consider adding label
Wiki liketo the issue.Changes subject to performance considerations have been evaluated, and tested against production-size data if applicable.
This pull request does not contain significant changes, and at least one appropriate reviewer has been selected.
The
In progresslabel has been removed from the issue.The
Pull requestlabel has been added to the issue.The pull request has been made ready for review by tapping the "Ready for review" button below the list of commits on the pull request page.
To be completed by the pull request reviewer
This section should be completed with reference to section Performing PR review of the Code and PR reviews wiki page.
The
In progresslabel has been added to the pull request in GitHub.The issue requirements have been read and understood (along with any relevant emails and/or Slack messages).
The correct base branch is specified, and that base branch is up-to-date in the local source.
The issue branch has been checked out locally, and had the base branch merged into it.
All automated tests pass successfully.
Ensure the implementation satisfies the functional requirements.
Ensure that code changes are secure and align with the established coding practices, including code formatting and naming conventions.
Ensure that code changes are documented and covered with automated tests as applicable.
Ensure that code changes are well-suited for informal reasoning.
Ensure that changes are documented for the end-user (a software engineer in the case of TG, or an application user in the case of TG-based applications).
If there are significant changes (described above), special attention has been paid to them.
Marked the task items in section "Significant changes" as completed to indicate that corresponding changes have been reviewed, improved if necessary, and approved.
The issue or issues addressed by the pull request are associated with the relevant release milestone.
To be completed by the pull request reviewer once the changes have been reviewed and accepted
The changes have been merged into the base branch (unless there is a specific request not to do so, e.g., they are to be released to SIT).
The issue branch has been deleted (unless the changes have not been merged - see above, or there is a specific request not to do so).
The
In progresslabel has been removed from the pull request.The
Pull requestlabel has been removed from the issue.