feat: add URL event loading with auto-refresh clean-branch(#448)

[DhanashreePetare]

Description

Fixes #448

This PR implements the ability to load event data from a URL with automatic refresh capability when cycling back to the first event. This enables live event display functionality for data teams.

Changes

Core Implementation

• URL Event Loading: Added loadEventsFromURL(url) method to EventDisplay class
  • Fetches event data from HTTP/HTTPS URLs
  • Uses cache: 'no-store' to ensure fresh data on every request
  • Tracks source URL and current event index
• Auto-Refresh on Loop-back: Automatically re-fetches events from URL when cycling from the last event back to the first
  • Enables live event display for continuously updating data sources
  • Falls back to cached event if refresh fails
• Manual Refresh: Added refreshEventsFromURL() method for manual data updates
• Helper Methods: isLoadedFromURL() and getEventSourceURL() for tracking loaded state

UI Integration

Added URL loading controls to both UI systems:

dat.GUI:

• "Load from URL" folder with URL input field
• Load and Refresh buttons
• Live status indicator

Phoenix Menu:

• "Load from URL" node with URL prompt
• Load and Refresh buttons
• Status label showing current source

Additional Improvements

• Extended PhoenixUI Interface: Added addEventURLLoader() method signature
• UIManager: Added setEventDisplay() method to wire EventDisplay to UI controls

Documentation

• Added comprehensive developer guide: url-event-loading.md
  • Usage examples (UI and programmatic API)
  • Auto-refresh behavior explanation
  • Implementation details
  • Expected data format
  • Error handling and CORS considerations

Testing
✅ All tests passing (164/164 tests phoenix-event-display, 176/176 tests phoenix-ng)

• Unit tests for existing functionality maintained
• TypeScript compilation clean
• ESLint passing for modified files

---

[sponce]

Thanks a lot for this @DhanashreePetare. I suppose we can close #764 ?

Concerning this one, I did not have time to test it fully, I've just read the code. It looks pretty good, but I have questions on the support for reloading : you are relying on the fact that the last event is being viewed and the new one is event 0. I suppose that this will also trigger if we do not cycle and I'm just selecting by hand these 2 events one after the other. Not sure this is desirable.
Besides, what I had in mind in the issue was only the cycling mode of cycle-event-component. which already handles the reload and in the indexing part through fileLoader.reloadLastEvents. fileLoader in turns already handles the parsing of the data (supporting everal file types) so I suppose this is the natural place to put the loading code. Basically if the filename is a url, you switch to that mode.
Does that make sense. I think the code will be more generic and with less duplication.

[DhanashreePetare]

Thanks a lot for this @DhanashreePetare. I suppose we can close #764 ?

Concerning this one, I did not have time to test it fully, I've just read the code. It looks pretty good, but I have questions on the support for reloading : you are relying on the fact that the last event is being viewed and the new one is event 0. I suppose that this will also trigger if we do not cycle and I'm just selecting by hand these 2 events one after the other. Not sure this is desirable. Besides, what I had in mind in the issue was only the cycling mode of cycle-event-component. which already handles the reload and in the indexing part through fileLoader.reloadLastEvents. fileLoader in turns already handles the parsing of the data (supporting everal file types) so I suppose this is the natural place to put the loading code. Basically if the filename is a url, you switch to that mode. Does that make sense. I think the code will be more generic and with less duplication.

Thanks for the thoughtful review!

You're absolutely right on both points:

• Auto-refresh should be tied strictly to the cycling flow, not any manual last→first navigation.
• Reload logic belongs in the existing cycling pipeline (cycle-events → fileLoader.reloadLastEvents), which already handles parsing for multiple formats.

What I've changed:

• Removed the loop-back refresh from EventDisplay.loadEvent().
• Kept the URL methods (loadEventsFromURL, refreshEventsFromURL, isLoadedFromURL, getEventSourceURL) for manual/UI usage.
• Enhanced fileLoader.reloadLastEvents() to force cache: 'no-store' so we always bypass caches when reloading.

Behavior now:

• Auto-refresh happens only when cycling wraps (last → first) and the "reloading" mode is enabled in the cycle UI.
• Manual selections (including last→first by clicking) do not trigger refresh.
• URL sources integrate through fileLoader, reusing its parsing for JSON/JiveXML/zip as before.

This matches the original intent from #448 where the cycling flow would reload URLs to create a live event display.