> 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
> > 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
> > use borrower.method instead of borrower->method etc. Secondly, reading
> > borrower.something might not immediately tell you that something is a
> > 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.
Koha-devel mailing list
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/