views.py render() and dictionaries

[notchris1]

Is it worth moving the dictionary out of the render function and passing it in with a variable name. To me it seems neater with regards to extending veiws .py in the future. (Breaking the code into logical functions etc)

[notchris1]

Oh and haha 69, look its funny, its funny, seriously!

[McCrea]

I agree that views.py needs refactoring - probably breaking out into multiple packages. But which dictionary are you referring to? I feel that there would be some mileage in creating a package for generic methods useful in views.py such as checking the user has permission to view a named file.

[notchris1]

The dictionaries that exist inside the render() function, that refer to the tagged bits in the templates, for instance in app. I appreciate they are not going to get shorter by doing this, however it makes it neater when they get longer.

[McCrea]

I see. I think that can just be done using a bit of common sense - I dare say that anyone who needed to make the dictionaries much larger would move them into a variable. As it stands I know that at least one of the more complex dictionaries builds up a list in a variable and then uses that as one of the entries in the dictionary passed to render().

[notchris1]

That's my point exactly, I'm saying is it worth considering sticking them into a variable, it bugs me.

[McCrea]

Most of them aren't that large. If a particular dictionary gets particularly huge then I dare say that whoever is working on it will have the sense to pull it out into a variable but, as it stands, I don't think many of them are more than a couple of entries. Feel free to change it if you like, but I think there are more important things to do than refactoring every line of code you see.

[notchris1]

You make a good point, however I feel issues that are tiny are still issues (perhaps indicators of larger issues sometimes) , and need to be tracked even if they are not priorities, attention to detail is important.

[McCrea]

There are more than 10,000 lines of code in this repository. About half of them need attention. You'd better start creating tickets if you want to be finished in time for final...

[notchris1]

Point duly noted, idiocy reigned in.

[McCrea]

I don't disagree about attention to detail, I just think there are lots of issues like this, and lots of them (like this issue) will be subjective. I think that the fact that we have some literal dictionaries which are quite long is less likely to be noticed by the markers than a lack of features.

[notchris1]

I wasn't being flippant

[McCrea]

I got that.