<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
</span>What do you suggest? It's much easier to always get and pass a full<br>
object than sometimes a smaller one without knowing exactly what it<br>
represents (which methods you can call on it).<br>
I don't think it will hurt perfs too much.<br>
Of course there will certainly be some rooms for improvements here, it<br>
should not be a rule written in stone.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> We start passing these objects to the templates now too, making it possible<br>
> to call methods from the template. It is possible, but do we really want<br>
> that? More code ends up in the template, maybe harder to find since you now<br>
> use borrower.method instead of borrower->method etc. Secondly, reading<br>
> borrower.something might not immediately tell you that something is a method<br>
> instead of a column.<br>
<br>
</span>Yes, I don't think it's a good thing. We should avoid calling methods<br>
in template, only accessors. If the method is trivial, I'd say it<br>
could be ok.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> In other cases we have added a sort of wrapper like Branches.GetName from<br>
> the Branches plugin.<br>
<br>
</span>That was to help us, and that will continue to help us, because the fk<br>
don't always exist.<br>
If should not hurt perf neither.<br></blockquote><div><br></div><div>We can work around the lack for fk constrains within our objects as well!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> I am interested to know if we want to enforce this wrapper approach for<br>
> instance, or just continue on the current road.<br>
<br>
</span>Where and why? :)<br>
<br>
Usually I don't think TT plugins should be used for such things. In an<br>
ideal world, we would manipulate objects in templates and<br>
library.branchname would display the library name (in a ideal world it<br>
would be library.name...).<br>
Or patron.library.branchname, but we should not need a plugin for<br>
that: Branches.GetName( patron.branchcode )<br></blockquote><div><br></div><div>I agree with this completely. I think it makes for a much more natural language and a cleaner implementation.</div><div><br></div><div>Kyle</div></div></div></div>