Agreed with what Kyle has said here.


Especially with the part about considering templates as our View and that View 
logic is OK. I don’t think we should be handling View logic in the controller 
script if it can be avoided.


David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007



Office: 02 9212 0899

Direct: 02 8005 0595


[] On Behalf Of Kyle Hall
Sent: Wednesday, 21 September 2016 2:37 AM
To: Jonathan Druart <>
Subject: Re: [Koha-devel] [Koha::Object] Related records and calling methods 
from templates


What do you suggest? It's much easier to always get and pass a full
object than sometimes a smaller one without knowing exactly what it
represents (which methods you can call on it).
I don't think it will hurt perfs too much.
Of course there will certainly be some rooms for improvements here, it
should not be a rule written in stone.


I agree. Passing the full object to the template will actually affect the 
performance the least. What we pass is a ref. If we start munging the data 
before we give it to the template, we are just adding needless overdead.


> We start passing these objects to the templates now too, making it possible
> to call methods from the template. It is possible, but do we really want
> that? More code ends up in the template, maybe harder to find since you now
> use borrower.method instead of borrower->method etc. Secondly, reading
> borrower.something might not immediately tell you that something is a method
> instead of a column.

Yes, I don't think it's a good thing. We should avoid calling methods
in template, only accessors. If the method is trivial, I'd say it
could be ok.


I think it's important to consider the template is our View, and logic is fine 
in the template as long as it's View logic. Formatting a date for example. It 
shouldn't matter whether we call and object method or a plugin to handle that 
view logic. In fact, I'd put money on calling an object method being faster and 
more efficient.


> In other cases we have added a sort of wrapper like Branches.GetName from
> the Branches plugin.

That was to help us, and that will continue to help us, because the fk
don't always exist.
If should not hurt perf neither.


We can work around the lack for fk constrains within our objects as well!


> I am interested to know if we want to enforce this wrapper approach for
> instance, or just continue on the current road.

Where and why? :)

Usually I don't think TT plugins should be used for such things. In an
ideal world, we would manipulate objects in templates and
library.branchname would display the library name (in a ideal world it
would be
Or patron.library.branchname, but we should not need a plugin for
that: Branches.GetName( patron.branchcode )


I agree with this completely. I think it makes for a much more natural language 
and a cleaner implementation.



Koha-devel mailing list
website :
git :
bugs :

Reply via email to