Role of django filters. Filtering or upfront formatting within the view?

I would like to hear your opinion about this.

I have a django application, where the data obtained from the model are rough. To make them nicer I have to do some potentially complex, but not much, operation. An example, suppose you have a model where the US state is encoded as two letter codes. In the html rendering, you want to present the user the full state name. I have a correspondence two-letters -> full name in another db table. Let's assume I don't want to perform joins.

I have two choices

1. have the view code extract the two-letter information from the model, then perform a query against the second table, obtain the full name, and put it in the context. The template renders the full state name.
2. create a custom filter which accepts two-letter codes, hits the db, and returns the full-length name. Have the view pass the two-letter information into the context, and put in the template the piping into the filter. T开发者_JS百科he filter renders the two-letter code as a full string.

Now, these solutions seem equivalent, but they could not be, also from the design point of view. I'm kind of skeptical where to draw the line between the filter responsibility and the view responsibility. Solution 1 is doing the task of the filter in solution 2, it's just integrated within the view itself. Of course, if I have to call the filter multiple times within the same page, solution 1 is probably faster (unless the filter output is memoized).

What's your opinion in terms of design, proper coding and performance?

It seems to me your model should have a method to do the conversion. It seems like extra work to make a filter, and I don't think most Django developers would expect that sort of thing in a filter.

A filter is meant to be more generic - formatting and displaying data rather than lookups.

My oppinion is that the first solution is much cleaner from a design point of view. I'd like to see the template layer as just the final stage of presentation, where all the information is passed (in its final form) by the view.

It's better to have all the "computation logic" in the view. That, way:

• It's much easier to read and comprehend (especially for a third party).

• I you need to change something, you can focus on a particular view method and be sure that everything you need to change is in there (no need to switch back and forth from view to template).

As for performance, I think your point is right. If you want to do the same lookup multiple times, the 2nd solution is worse.

Edit: Referring to ashchristopher's comment, I was actually trying to say that it definitely does not belong to the template. It's never really clear what business logic is and where the line between "data provision" and "business logic" lies. In this case it seems that maybe ashchristopher is right. Transformation of state codes to full state names is probably a more database related encoding matter, than a business logic one.