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