Great comments, David! Thanks for taking the discussion further:) Some comments in line below: Fra: David Cook [dcook@prosentient.com.au]
I think that this also has the potential to increase separation of business and presentation layers. Of course, I think presentation is important, but if we focus on making sure that useful data is coming out, we're less likely to cheat and combine them when we probably shouldn't.
I agree - this would perhaps be the best takeaway, IMO.
2) I'm not sure that I understand what you mean when you ask "should Koha's templates make use of its own APIs?".
Do you mean using the API via Javascript on the template, or using the API via LWP in the Perl script?
Yes, I was thinking about such cases, as in recent enhancements using ajax+datatables for fetching data asynchronously. I also think it can be used for more static data, which rarely change. Say for example the list of branches (we have around 30) which populates dropdown several places the staff interface. If this was fetched after page load, by an AJAX request to, say, GET koha/rest/v2/branches, we could set the Cache expiration headers, (to a day, or a month, I dunno) then the browser would cache this particular request, and thus not touch the database at all except when cache expires. For frequently used pages this could lead to a lot of less traffic to the database. Then there is the problem of when you actually DO change this "mostly" static data, like branches... Well, either you can wait until cache expires, you can force to reload (Cltr +R, or Cltr + F5 in most browser), or we must implement some logic on updates which modifies the cache expiration headers. Some more benefits of Koha using its own APIs: - They are kept up to date since they are used by Kohas core - More thought is being put into layout, organization and implementation of the API, as it not just for "someone else", some third-party integration, but for Koha itself. Regards, Petter Goksøyr Åsen Deichmanske bibliotek / Oslo Public Library