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 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: [email protected] [mailto:[email protected]] On Behalf Of Kyle Hall Sent: Wednesday, 21 September 2016 2:37 AM To: Jonathan Druart <[email protected]> Cc: [email protected] 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 library.name...). 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. Kyle
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
