flip.nvflare.components.validation_json_generator
=================================================

.. py:module:: flip.nvflare.components.validation_json_generator


Classes
-------

.. autoapisummary::

   flip.nvflare.components.validation_json_generator.ValidationJsonGenerator


Module Contents
---------------

.. py:class:: ValidationJsonGenerator

   Bases: :py:obj:`nvflare.app_common.widgets.validation_json_generator.ValidationJsonGenerator`


   Stock NVFLARE ``ValidationJsonGenerator``, dispatched manually by FLIP's ServerEventHandler.

   Subclasses ``nvflare.app_common.widgets.validation_json_generator.ValidationJsonGenerator`` so
   the results accumulation (METRICS *and* COLLECTION / T2 leaf handling), numpy-float JSON
   encoding and path-safe output track upstream instead of a drifting vendored copy (the fork had
   only the METRICS branch and a plain ``json.dump``). The default ``results_dir`` /
   ``json_file_name`` are identical to stock, so the constructor is inherited unchanged.

   The only FLIP-specific behaviour is dispatch. NVFLARE would auto-handle events through
   ``handle_event``; FLIP instead routes them through ``ServerEventHandler``, which calls
   ``handle_evaluation_events``. Because this component is still registered (so its
   ``handle_event`` is auto-fired for every event), ``handle_event`` is suppressed here — otherwise
   each validation result would be recorded twice — and the real work is delegated to stock's
   implementation from ``handle_evaluation_events``.


   .. py:method:: handle_event(event_type: str, fl_ctx: nvflare.apis.fl_context.FLContext) -> None


   .. py:method:: handle_evaluation_events(event_type: str, fl_ctx: nvflare.apis.fl_context.FLContext) -> None

      FLIP integration point — ServerEventHandler dispatches events here, not via handle_event.