On 02/13/2015 04:11 PM, Thomas De Schampheleire wrote:
Hi,
Hi - I owe you a system overview. it is on my todo list! ;-)
I have a question about how one should handle the split between controllers and templates. Let's take one particular example: the difference between the list of pull requests of a particular repository (/pull-request) and the list of 'my pull requests'. For 'all pull requests' of a repo, the actual data is rendered from the controller and placed in a variable c.pullrequest_data, which is expanded from the template. The data is loaded statically (no AJAX) and paged at the controller side. For 'my pull requests', the actual data is fetched dynamically, via AJAX, and no paging is performed. Since I want to line up these two lists of very similar data (at a minimum the way it is displayed), I would like to know what you consider the best approach wrt this template/controller split.
It relates to what has been discussed recently: Whether we should use server side templating (which is indexable by bots and easy on the browser (but might require more bandwidth and have higher latency)) or if we want a more rich javascript browser app that fetches data from 'web services' and do the 'templating' client side.
You can argue both ways. I think it is a bit overkill to do 'my pull requests' dynamically. But in the places where lists can grow long, we should have 'infinite scroll' where data is loaded as you scroll down in the list.
Other feedback on this topic is also welcome. (Side questions: - what is the 'c' for in c.pullrequest_data, 'controller'?
c is the context where the controller sets values that the template can use.
- what is the difference between 'c' and 'h' ?
h is a shortcut for kallithea/lib/helpers.py . Mainly various convenience functions mainly used in templates.
/Mads _______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
