templates and controllers

[Mads Kiilerich]

On 02/22/2015 07:13 PM, Thomas De Schampheleire wrote:
> On Sun, Feb 22, 2015 at 4:56 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> 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.
> One concern is how usable/functional Kallithea is when Javascript is
> disabled in the browser.
> Good practice says that the core functionality should still work, so
> loading async for the initial code would not be good, unless you also
> handle something in <noscript>.
>
> Then the principle described in
> http://pylons-webframework.readthedocs.org/en/latest/helpers.html#partial-updates-with-ajax
> could be better: have the initial load include the data template from
> pure mako, and let the pager load new pages dynamically. When
> javascript is disabled, everything still works.

That makes sense ... and following some Pylons "best practice" is 
probably a good idea when we use Pylons.

I can however also see that it makes sense to assume javascript is 
enabled and just make it mandatory. It can make it easier for us as 
developers and can give a better user experience. But it probably makes 
sense to  stick to the "use javascript sparingly" when we use 
pylons/mako. A switch to making javascript "very" mandatory could be 
tied to switching to something angular-ish.

>> As a simple short term improvement we could replace c.journal_data in the
>> template with an include of journal_data.html .
> Yes, similar to what I did in my last pullrequest series right?
> There, I could get rid of the variable c.foo_data altogether as the
> dynamic aspect was not used.
>
> But in the case of journal, since dynamic loading is used, the
> variable still would exist.
> I think the way to solve this differently, is to have two controller
> methods, one serving the full page and one the data portion. This is
> how 'my pullrequests' was handled initially (before my patches).
> Then you don't need a magic 'partial' variable in the HTTP request.
>
> Is this correct reasoning?

I don't know if it is correct, but yes, I totally agree ;-)

/Mads