#240 Page views and Page context classes

[duker33]

Closes #240

• Create page views display. It's explicit class module with classes for DB templates processing
• Create page context. Move base context classes to pages module

[ArtemijRodionov]

let raise AttributeError if an item not in STORED

[ArtemijRodionov]

Suggested change

	class Page:
	class RenderedPage:

[duker33]

@artemiy312 , let's look at the shopelectro.views.catalog.CategoryPage class for example.
Here we have pretty the same situation: view uses some template and given context to render response body. But we don't call it RenderedCategoryPage.

So, let's leave the Page name

[ArtemijRodionov]

Should we spawn new View entity? I believe that this will lead to ambiguity, because we will have two type of different things with the same name. I'd prefer to avoid this term.

We may use this as part of context classes instead of db view or just use these classes without mentions about View

Up to you

[duker33]

@artemiy312 , this class has the view nature. That's why every other name for this class will be bad.
It's not good to spawn the one other view module, i agree.
The best approach is to put the class to the existing view module. But we'll have problems with cyclic imports in this case.
So, new module name is just trade off to make django's standard design pleasure.

I'll add some of this words to the top of db_view module and leave it as is

[ArtemijRodionov]

this class has the view nature

But it isn't. A view is a callable which takes a request and returns a response. These classes don't match with this term

[duker33]

@artemiy312 , y, you are right. So, we need some term for "template renderer with context".
I propose "Display". We already used it as part of property name page.display_h1 for example.

I'll rename module