templates and controllers
mads at kiilerich.com
Sun Feb 22 10:56:26 EST 2015
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 =
>>> controllers/forks.py:126: c.forks_data =
>>> controllers/pullrequests.py:207: c.pullrequest_data =
>>> controllers/summary.py:111: readme_data =
>>> controllers/admin/gists.py:234: rendered =
>>> controllers/admin/admin.py:144: c.log_data =
>>> controllers/journal.py:210: c.journal_data =
>>> controllers/journal.py:353: c.journal_data =
>>> 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
> 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.
More information about the kallithea-general