On 02/21/2015 09:35 PM, Thomas De Schampheleire wrote:
On Tue, Feb 17, 2015 at 4:26 AM, Mads Kiilerich <[email protected]> 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
_______________________________________________
kallithea-general mailing list
[email protected]
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
