search

IPTnet / ipt_connect

GNU General Public License v3.0
9 stars 19 forks source link

The whole `params` object to templates #81

Open nickkolok opened 5 years ago

nickkolok commented 5 years ago

All the templates which are customizable should receive the whole params object, not its fields (see request calls in views.py).

Is it possible to magically make params enabled for all templates without explicit mentioning?

vbonvin commented 5 years ago

What for? The philosophy I tried to adopt (even if not always really respected...) is to pass the minimum amount of information to each render.

Is it possible to magically make params enabled for all templates without explicit mentioning?

Not sure I understand what you would like to do...

nickkolok commented 5 years ago

As for now (2978f6aa045a361175f3a0b34fb14e6ffc02b147), any template which requires head.html (i.e. almost any template) has to know tournament name and toknow whether pools are enabled. Moreover, unhardcoding "IPTdev" (see #78) will make the access app_version necessary. If we already have three parameters passed, then why should we list all the three every time?

vbonvin commented 5 years ago

But you pass the tournament name via params in view.py, so it's not really called in the templates themselves...?

If I understand correctly, what you want is to overload the render function so that it load params by default, but it seems to be a lot of hassle just to avoid calling params in each view.

nickkolok commented 5 years ago

Well... A typical render call i smth like this:

return render(request, 'IPT%s/participant_detail.html' % params.app_version, {'participant': participant, "average_grades": average_grades, 'params': params})

I think it is rather easy to write a wrapper function:

return wrapped_render(request, 'participant_detail.html', {'participant': participant, "average_grades": average_grades})

It looks much better, doesn't it?

vbonvin commented 5 years ago

It looks much better, doesn't it?

Certainly. If it is necessary then, that's another question ;)

But there is no point debating if such things should be implemented or not; if you want to do it, go ahead. As long as it does not break the code, I'm completely fine with you making it more elegant - and it's always a good way to learn.

nickkolok commented 4 years ago

The issue looks pretty simple: we just have to create a function that wraps another function - and the use it :) Nothing Django-specific.