Split CatalogPage's monolith code

[duker33]

shopelectro.views.catalog.CategoryPage currently consists of this steps:

• get products
• filter tags
• get template context
• paginate products

All these steps are semantically separated from CategoryPage and from each other.
Here is good code draft example for get products + filter tags.

class CategoryPage:

    def __init__(self, category_id):
        pass

    def products(self) -> 'QuerySet':
        return None

    def get_context_data(self):
        return {}


class TaggedCategoryPage:
    def __init__(self, page: CategoryPage, tags):
        self.super = page

    def products(self) -> 'QuerySet':
        return super.products.filter(smth=anyth)

    def get_context_data(self):
        context = self.super.get_context_data()
        data = {}
        return {
            'all_products': products,
            **data,
            **context,
        }

But use in this task traditional inheritance instead of objects composition

[ArtemijRodionov]

@duker33
I believe, that inheritance is not the best solution for this issue.
Currently the implementation does not look helpful and even vice versa, because we are going to create a complex inheritance structure, that will decrease view performance and will be still monolith. And in final we will use only one class from this structure that can be presented as single class as it is right now

[duker33]

@artemiy312 , inheritance is only step for objects composition.

But even with inheritance we'll switch to named chunks of code with separated responsibility. Instead of one huge get_context_method with all-in-one.

With inheritance responsibility will be separated, but badly organized.
And it's task of objects composition to organize it well.
We'll enable composition after this task tree will fully

class AbstractContext:
	def __init__(self, super: CatalogContext):
		self.super = super


class CatalogContext(AbstractContext):
	
    def products(catalog):
		return DB.fetch_prods(catalog)
		
	def get_context_data():
		return {...}  # something simple only about catalog

class TaggedCatalogContext:
    def products(tags):
		return self.super.products().and_aother_fetch(catalog)
		
	def get_context_data():
		return {
			**self.super.get_context_data(),
			... # and something simple only about tags
		}
		
class PaginatedCatalogContext:
	...
	
class DBTemplateContext:
	...

class CatalogView:
	def get_context_data(category_id, page_num):
		category = some_fetch(category_id)
		context = CatalogContext(category) | PaginatedCatalogContext(page_num)
		return context.get_context_data()

class TaggedCatalogView:
	def get_context_data(category_id, page_num, tags):
		category = some_fetch(category_id)
		context = (
			CatalogContext(category)
			| PaginatedCatalogContext(page_num)
			| TaggedCatalogContext(tags)
			| DBTemplateContext(tags)
		)
		return context.get_context_data()

In this case we can decrease amount of composited code for individual url

[duker33]

discussed this task with Artemiy via call.
I'll implement objects composition in this task. I'll increase hours count for it

[duker33]

broke pdd rules here. So increase time. Wasted it for arch

[0pdd]

@duker33 4 puzzles #566, #567, #568, #569 are still not solved.

[0pdd]

@duker33 7 puzzles #566, #567, #568, #569, #577, #578, #579 are still not solved.

[0pdd]

@duker33 all 7 puzzles are solved here: #566, #567, #568, #569, #577, #578, #579.