{"id":929,"date":"2024-03-25T13:44:17","date_gmt":"2024-03-25T13:44:17","guid":{"rendered":"https:\/\/codenerix.com\/?p=929\/"},"modified":"2025-02-10T05:16:37","modified_gmt":"2025-02-10T05:16:37","slug":"unlocking-advanced-data-transformation-in-django-codenerix-a-complete-guide","status":"publish","type":"post","link":"https:\/\/codenerix.com\/en\/unlocking-advanced-data-transformation-in-django-codenerix-a-complete-guide\/","title":{"rendered":"Unlocking Advanced Data Transformation in Django CODENERIX: A Complete Guide"},"content":{"rendered":"\n

In this guide, we will cover how to transform data or produce new data by calculating existing data, and we will go through the process of building our widgets using AngularJS for a ModelForm. Some of the ways explained here will follow the standard Django<\/strong> way of doing things, while others will follow the CODE<\/span>NERIX<\/span><\/a><\/strong>\u00a0way.<\/p>\n\n\n\n

When the software grows and matures, we usually need to customize some things better and add newer features over the existing ones. One of the most basic needs is data generation from other fields or data transformation while saving the information in the database.<\/p>\n\n\n\n

Producing new data over existing ones is usually a straightforward step. Let’s explore it travelling from the server (backed) to the user (frontend):<\/p>\n\n\n\n

1. Overloading the save() method in your model<\/h2>\n\n\n\n

This is a pretty straightforward backend solution<\/strong> solution. In your model, you create a new save() method that calls to super().save(). This can be done in two ways:<\/p>\n\n\n\n

The first one is by modifying data before it gets written to the database:<\/p>\n\n\n\n

self save(self):\n  # Use existing data to setup the custom field\n  self.custom_field = modifier(self.existing_fields)\n  # Save and return returned data to keep consistency\n  return super().save()<\/pre>\n\n\n\n
The second one is by modifying data and saving it again; in this way, you can pick up the PK from the object after calling super().save()<\/strong> and use it to recalculate it. (NOTE:<\/span><\/strong> if you have to save twice in your save()<\/strong> method, it usually means what you are doing is not a good idea)<\/p>\n\n\n\n
self save(self):\n  # Save existing data\n  super().save()\n  # Calculate seed based on the regiter's PK\n  self.seed = create_seed_based_on_register_pk(self.pk)\n  # Save it again and return returned data to keep consistency\n  return super().save()<\/pre>\n\n\n\n
The third method extends the second one by modifying other models’ data after this one is written to the database. This way, we can pick up the PK<\/strong> from the object after calling super().save() and use it with the other model. A common example of this could be to add the just created object into an existing ManyToMany<\/strong> relationship:<\/p>\n\n\n\n
self save(self):\n  # Save existing data\n  answer = super().save()\n  # Lookup for the other object\n  other = OtherModel.objects.filter(...).first()\n  # Add our selves into the relationship\n  other.custom_related_field.add(self)\n  # Answer back keeping consistency between calls\n  return answer<\/pre>\n\n\n\n
2. Using Django signals<\/h2>\n\n\n\n
This is a backend solution<\/strong> based on something that Django implements called signals<\/strong>. They are a great tool in complex scenarios, but keep in mind that they make the code harder to maintain, and those should be used only in situations where the other methods wouldn’t work. Read directly from Django’s<\/strong> documentation how to use signals<\/strong>.\u00a0https:\/\/docs.djangoproject.com\/en\/5.0\/ref\/signals\/<\/a><\/p>\n\n\n\n
Signals<\/strong> can be incredibly useful in complex scenarios where different components need to react to events or actions in a decoupled manner. For example, you might want to trigger specific actions whenever a new user registers, a post is created, or an order is placed.<\/p>\n\n\n\n
Signals<\/strong> introduce an element of indirection in your code, making it harder to follow the control flow. Since signals allow disparate parts of your application to interact, tracing the logic executed when a signal is triggered can sometimes be challenging. This can lead to difficulties in debugging and maintaining the codebase, especially as the application grows in complexity.<\/p>\n\n\n\n
Example of pre_save<\/strong> signal:<\/p>\n\n\n\n
from django.dispatch import receiver\nfrom django.db.models.signals import pre_save\nfrom django.template.defaultfilters import slugify\n\n@receiver(pre_save)\ndef my_callback(sender, instance, *args, **kwargs):\n    instance.slug = slugify(instance.title)<\/pre>\n\n\n\n
Example of post_save<\/strong> signal:<\/p>\n\n\n\n
from django.dispatch import receiver\nfrom django.db.models.signals import post_save\nfrom django.contrib.auth.models import User\n\n@receiver(post_save, sender=User)\ndef create_profile(sender, **kwargs):\n    # write you functionality\n    pass<\/pre>\n\n\n\n
3. The clean_<field>() methods at Forms classes<\/h2>\n\n\n\n
This is a backend solution<\/strong> based on Django<\/strong> clean_()<\/strong> methods.<\/p>\n\n\n\n
Django clean_<field>()<\/strong> methods are special methods used within Django<\/strong> form classes to clean and validate individual form fields. They are automatically called during form validation after the respective field’s default validation has been performed.<\/p>\n\n\n\n
Here’s how clean_<field>()<\/strong> methods work:<\/p>\n\n\n\n
    \n
  1. Validation and Cleaning:<\/span><\/strong> When you define a form class in Django, each form field gets its method for validation and cleaning. These methods are named clean_<field_name>(), <\/strong>in which <field_name><\/strong> is replaced by the name of the field.<\/li>\n\n\n\n
  2. Execution Order:<\/span><\/strong> These methods are executed after the default field validation. Django first checks the field’s built-in validators, and then if there are any clean_<field>()<\/strong> methods, it calls them one by one.<\/li>\n\n\n\n
  3. Customized Cleaning Logic:<\/span><\/strong> In your form class, you can define these methods to implement custom validation and cleaning logic for individual fields. This is particularly useful when you need to perform complex validation or when the validation depends on the values of multiple fields.<\/li>\n\n\n\n
  4. Error Handling:<\/span><\/strong> Inside these methods, you can raise a ValidationError<\/strong> if the field’s value doesn’t pass your custom validation criteria. This error can contain a message explaining the reason for the validation failure, which will be displayed to the user.<\/li>\n<\/ol>\n\n\n\n
    Here’s a simple example demonstrating the usage of clean_<field>()<\/strong> methods in a Django<\/strong> form:<\/p>\n\n\n\n
    from django import forms\n\nclass MyForm(forms.Form):\n    age = forms.IntegerField()\n\n    def clean_age(self):\n        age = self.cleaned_data.get('age')\n        if age is not None and age < 18:\n            raise forms.ValidationError(\"You must be 18 or older to use this service.\")\n        return age\n<\/pre>\n\n\n\n
    In this example, the clean_age()<\/strong> method checks if the provided age is under 18. If it is, it raises a ValidationError<\/strong> with a corresponding error message. Otherwise, it returns the cleaned (validated) value<\/strong>.<\/p>\n\n\n\n
    Now let’s see how we can use the clean_<field>()<\/strong> methods to rewrite data in another field:<\/p>\n\n\n\n
    from django import forms\n\nclass MyForm(forms.Form):\n    start_date = forms.DateField()\n    end_date = forms.DateField()\n\n    def clean_start_date(self):\n        start_date = self.cleaned_data.get('start_date')\n        end_date = self.cleaned_data.get('end_date')\n\n        # Check if start_date is after end_date\n        if start_date and end_date and start_date > end_date:\n            # If start_date is after end_date, swap the values\n            self.cleaned_data['start_date'] = end_date\n            self.cleaned_data['end_date'] = start_date\n\n        return start_date\n<\/pre>\n\n\n\n
    4. Create a custom widget<\/h2>\n\n\n\n
    This is one of the most beautiful approaches because it lets you work with the form from the Angular JS point of view without messing with custom controllers (which is the last point of this manual). This is a frontend solution<\/strong> designed from the backend.<\/p>\n\n\n\n
    This is usually the best approach when you post-process data in the form (straight inside the browser). You need to know Angular JS\u00a0programming to go with this solution if you want to make big things, but for simple changes, it is perfectly fine.<\/p>\n\n\n\n
    Process:<\/span><\/strong><\/p>\n\n\n\n