Signals from BaseView

The lback.views.base_view.BaseView class, serving as the foundation for all view handlers, emits signals throughout its request dispatching process. These signals offer valuable insights into the lifecycle of a request within a view and enable you to execute custom logic at pivotal moments.

Signal Name	Description	Arguments (kwargs)
view_dispatch_started	Emitted at the very beginning of the dispatch() method, indicating that an incoming request is about to be handled by a specific view instance.	sender (BaseView): The instance of the view handling the request.<br>``view_instance`` (BaseView): A direct reference to the view instance (same as sender).<br>``request`` (Request): The incoming request object.<br>``method`` (str): The HTTP method of the request (e.g., “GET”, “POST”).<br>``path`` (str): The URL path of the incoming request.
view_method_not_allowed	Emitted when the HTTP request method is not permitted by the methods attribute of the view (e.g., a POST request attempting to access a view configured for GET only). This occurs before raising a MethodNotAllowed exception.	sender (BaseView): The view instance.<br>``view_instance`` (BaseView): A direct reference to the view instance.<br>``request`` (Request): The incoming request object.<br>``method`` (str): The disallowed HTTP method.<br>``path`` (str): The URL path of the incoming request.<br>``allowed_methods`` (list of str): A list of methods explicitly allowed by the view.
view_handler_not_implemented	Emitted when the view technically allows a specific HTTP method but lacks a corresponding callable handler method (e.g., a “GET” request is permitted, but no get() method is defined in the view). This occurs before raising a NotImplementedError.	sender (BaseView): The view instance.<br>``view_instance`` (BaseView): A direct reference to the view instance.<br>``request`` (Request): The incoming request object.<br>``method`` (str): The HTTP method for which the handler is absent.<br>``path`` (str): The URL path of the incoming request.<br>``handler_name`` (str): The expected name of the handler method (e.g., “get”, “post”).
view_dispatch_succeeded	Emitted after a view’s method handler (e.g., get(), post()) has successfully executed and returned a response.	sender (BaseView): The view instance.<br>``view_instance`` (BaseView): A direct reference to the view instance.<br>``request`` (Request): The incoming request object.<br>``method`` (str): The HTTP method that was successfully handled.<br>``path`` (str): The URL path of the incoming request.<br>``response`` (Any): The response object or data returned by the successful handler.

Signals from APIDocs

The lback.api.docs.APIDocs class, which handles the generation of OpenAPI (Swagger) documentation, emits signals at various key points throughout its documentation process. These signals offer powerful hooks for monitoring, extending, or deeply customizing how your API documentation is generated and integrated.

Signal Name	Description	Arguments (kwargs)
api_docs_initialized	Emitted right after the APIDocs instance is created and set up with its initial configuration (like title, version, and description).	sender (APIDocs): The specific instance of the API documentation generator.<br>``title`` (str): The configured title for the API documentation.<br>``version`` (str): The configured API version.<br>``description`` (str): The configured description of the API.
api_docs_collection_started	Emitted just as the collect_documentation() method begins. This signifies the start of gathering documentation details from all registered routes and views.	sender (APIDocs): The API documentation generator instance.
api_docs_collection_finished	Emitted once the collect_documentation() method has finished scanning all routes and views.	sender (APIDocs): The API documentation generator instance.<br>``paths_count`` (int): The total count of unique API paths that were successfully documented.<br>``processed_routes`` (int): The number of routes that were processed for documentation, meaning an attempt was made to document them.<br>``skipped_routes`` (int): The number of routes that were not documented, often due to missing information or uncallable handlers.
api_docs_route_documented	Emitted each time a specific route’s HTTP methods are successfully inspected and documented for the OpenAPI specification.	sender (APIDocs): The API documentation generator instance.<br>``route`` (Route): The route object that was documented.<br>``path`` (str): The original path string for the route.<br>``documented_methods_count`` (int): The number of individual HTTP methods (e.g., GET, POST, PUT) found and documented for this particular route.
api_docs_route_skipped	Emitted when a route cannot be documented. This is typically due to issues like missing HTTP methods on its associated view class, or if no callable handlers are found for the declared methods.	sender (APIDocs): The API documentation generator instance.<br>``route`` (Route): The route object that was skipped.<br>``reason`` (str): A descriptive string explaining why the route was skipped (e.g., “no_methods”, “no_callable_methods”).
openapi_spec_generated	Emitted after the complete OpenAPI specification dictionary (the final Swagger JSON structure) has been successfully assembled.	sender (APIDocs): The API documentation generator instance.<br>``spec`` (dict): The entire OpenAPI specification dictionary.
api_docs_serializer_schema_registered	Emitted just before a BaseModelSerializer class is analyzed to generate its corresponding OpenAPI schema and add it to the global components.	sender (APIDocs): The API documentation generator instance.<br>``serializer_class`` (Type`[:py:class:`~lback.api.serializer.BaseModelSerializer]): The specific serializer class being processed.<br>``schema_name`` (str): The name under which this schema will be known within the OpenAPI #/components/schemas/ section.
api_docs_serializer_schema_registered_finished	Emitted after a serializer’s schema has been fully generated and successfully added to the OpenAPI components section.	sender (APIDocs): The API documentation generator instance.<br>``schema_name`` (str): The name of the schema that was just registered.

Signals from BaseModelSerializer

The lback.api.serializer.BaseModelSerializer class, a foundational component for data serialization and validation within the framework, emits a comprehensive range of signals throughout its operational lifecycle. These signals are incredibly valuable, offering powerful extension points for auditing data operations, integrating with other parts of your application, or implementing custom logic at critical serialization and validation stages.

Signal Name	Description	Arguments (kwargs)
serializer_initialized	Emitted immediately after a serializer instance has been fully initialized and is ready for use.	sender (BaseModelSerializer): The specific serializer instance that was initialized.<br>``serializer`` (BaseModelSerializer): A direct reference to the same serializer instance (identical to sender).<br>``many`` (bool): Indicates if the serializer is configured to handle multiple model instances (e.g., a list of objects).<br>``partial`` (bool): Indicates if the serializer is configured to allow partial updates (i.e., not all required fields must be present).<br>``context`` (dict): Any context dictionary passed to the serializer upon initialization.
serializer_pre_serialize	Emitted just before the serialization process commences. This is the stage where a model instance (or instances) is about to be transformed into its dictionary representation.	sender (BaseModelSerializer): The serializer instance.<br>``serializer`` (BaseModelSerializer): A direct reference to the serializer instance.<br>``instance`` (Any or list): The model instance(s) that are currently being prepared for serialization.<br>``many`` (bool): Indicates if multiple instances are being serialized in this operation.
serializer_post_serialize	Emitted immediately after the serialization process has successfully completed, and the dictionary representation of the data is now fully available.	sender (BaseModelSerializer): The serializer instance.<br>``serializer`` (BaseModelSerializer): A direct reference to the serializer instance.<br>``serialized_data`` (dict or list of dict): The final data output from the serialization process.
serializer_validation_started	Emitted precisely when the validation process begins. This is the stage where raw input data is being processed and checked for correctness, prior to being converted into a clean, validated dictionary. Sensitive data like passwords will be masked within ``raw_data`` for security.	sender (BaseModelSerializer): The serializer instance.<br>``serializer`` (BaseModelSerializer): A direct reference to the serializer instance.<br>``raw_data`` (dict): The raw input data dictionary submitted for validation. (Note: sensitive fields like ‘password’ are masked).
serializer_validation_succeeded	Emitted when the entire validation process successfully finishes, providing the cleaned, type-converted, and fully validated data.	sender (BaseModelSerializer): The serializer instance.<br>``serializer`` (BaseModelSerializer): A direct reference to the serializer instance.<br>``validated_data`` (dict): The dictionary containing the validated and cleaned data.
serializer_validation_failed	Emitted when the validation process encounters one or more errors. This signal provides details about the validation failures.	sender (BaseModelSerializer): The serializer instance.<br>``serializer`` (BaseModelSerializer): A direct reference to the serializer instance.<br>``errors`` (dict): A dictionary where keys represent field names, and values are lists of associated error messages.<br>``exception`` (Exception, optional): The exception object if the validation failure was caused by an unexpected runtime error.
serializer_pre_save	Emitted just before a new model instance is created or an existing one is updated in the database, using the data that has already been validated by the serializer. Sensitive data like passwords will be masked within ``validated_data`` for security.	sender (BaseModelSerializer): The serializer instance.<br>``serializer`` (BaseModelSerializer): A direct reference to the serializer instance.<br>``validated_data`` (dict): The validated data dictionary (with sensitive fields masked) that is about to be used for the database save operation.<br>``instance`` (Any or None): The existing model instance being updated, or None if a brand new instance is being created.<br>``session`` (Any): The database session object that will be utilized for the save operation.
serializer_post_save	Emitted immediately after a model instance has been successfully either created or updated in the database.	sender (BaseModelSerializer): The serializer instance.<br>``serializer`` (BaseModelSerializer): A direct reference to the serializer instance.<br>``instance`` (Any): The newly created or updated model instance that was persisted to the database.<br>``session`` (Any): The database session object that was used for the save operation.