RE: Copropiedad Integral | Parking module administration

You are viewing a single comment's thread from:

RE: Copropiedad Integral | Parking module administration

View the full context

amosbastian (72)in #utopian-io • 6 years ago

Thanks for the contribution, @kit.andres! The ParkingLot classes seem to share some functions, so I was wondering if there isn't a better way to do implement them to prevent this (I am not sure, just thinking out loud!)?

Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.

To view those questions and the relevant answers related to your post, click here.

Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.
[utopian-moderator]

6 years ago in #utopian-io by amosbastian (72)

$0.00

1 vote

Sort:

Trending

[-]

kit.andres (65) 6 years ago (edited)

Hi @amosbastian. I took your recommendation to make a code refactoring of the buildings application views. therefore, I have taken the views.py file and I have split this into different files, depending on the specific modules that are being worked on. Here is the commit for these changes. This if to avoid a very long file (thousands of lines) with different modules functionalities. There are still many pending modules that should be included in this section.

Trying to find parts of code that can be reduced to common functions to reduce repetitive code, I have found that the process of the formsets (owners formset and leaseholders formset) in the Unit form, and in the update unit form can be reduced to a common function. In this commit are the code changes related to this update.

About the shared functions in the ParkingLot classes, I suppose you're talking about the def test_func(self):, or about the get_object(self, queryset=None): functions, per example. I tried to find a way to reduce it. All the classes defined in the ParkingLots module are inheriting their structure from the Django generic views (CreateView, UpdateView, DeleteView). These methods are inherited from Django, and have some specific function. Per example, the def test_func(self):should be overwritten to define the user permission. If this method returns False or None, a 403 forbidden error will be raised. The get_object(self, queryset=None): method is used for example, in an UpdateView to define the object that must be instanced in the form, in a DetailView to define the object that we want to show, and in a DeleteView to define the object that we want to delete. So, they are methods that must be defined in each class view. A way to reduce it could be to create a new class and define there the common methods in our classes, and define the classes inheriting from this new class, but I think that it only will be practical if our classes inherit from the same Django class based view. Per example if all classes in the ParkingLot module are inherited from the UpdateForm class, but all ParkingLot classes are inherited from different classes. Also, in this methods there are variables that depends of the url parameters, and the parameters are different in some views.

I can't find an efficient way to reduce it, but I will be ready to listen to all suggestions ;). Thank you sr, now the code is much better and more organized.

$9.17

2 votes

[-]