> > > 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/
