templates and controllers

[Mads Kiilerich]

On 02/21/2015 09:35 PM, Thomas De Schampheleire wrote:
> On Tue, Feb 17, 2015 at 4:26 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> On 02/15/2015 09:45 PM, Thomas De Schampheleire wrote:
>>>
>>> A quick search reveils:
>>>
>>> $ grep -rn '= render' controllers/
>>> controllers/followers.py:56:        c.followers_data =
>>> render('/followers/followers_data.html')
>>> controllers/forks.py:126:        c.forks_data =
>>> render('/forks/forks_data.html')
>>> controllers/pullrequests.py:207:        c.pullrequest_data =
>>> render('/pullrequests/pullrequest_data.html')
>>> controllers/summary.py:111:                        readme_data =
>>> renderer.render(readme.content,
>>> controllers/admin/gists.py:234:        rendered =
>>> render('admin/gists/edit.html')
>>> controllers/admin/admin.py:144:        c.log_data =
>>> render('admin/admin_log.html')
>>> controllers/journal.py:210:        c.journal_data =
>>> render('journal/journal_data.html')
>>> controllers/journal.py:353:        c.journal_data =
>>> render('journal/journal_data.html')
>>>
>>> Unless you see a good reason why the above is like that, this could be
>>> cleaned up...
>>
>> Agreed, it seems like some cleanup could make templates simpler or "better".
> It seems that this pattern is used to be able to return data-only in
> partial requests (those loaded via ajax/asynchtml javascript functions
> with HTTP_X_PARTIAL_XHR set).
>
> In the case of pullrequests, I don't think this is actually being
> using, but for example it is used for the journal.
>
> Not sure what to do with this...

We could make it simpler and always load the data async, also in the 
initial page load. We will have less code paths to consider if we always 
do it the same way. I would prefer that.

As a simple short term improvement we could replace c.journal_data in 
the template with an include of journal_data.html .

One future option could be to just return the data as json and generate 
the dom on the client side.

/Mads