[Koha-devel] An idea for consolidating staff interface header search forms

[dcook at prosentient.com.au]

Yeah, I'm not a fan of a single big file either. 

Owen, what's your motivation for the change? As the front-end person, I'm thinking maybe we should trust you on this one.

As for numbers...

It looks like that 1 file is 764 lines long (https://gitlab.com/koha-dev/koha-dev/-/commit/18831f86eabbb16aeccacc3e4cec54139b804f68). According to Gitlab, the stats are +1308 -1595. So it doesn't look like that much reduction of text. 

But it looks like maybe 21 files have been replaced by 1? Maybe that has removed unnecessary duplication.

Having 1 file would probably mean more git merge conflicts, but this also isn't an area that should change very often, so having it centralized could make those infrequent/rare changes easier to make all at 1 time.

In terms of performance, if a template cache is used, I think the header_searches.inc file should only need to be parsed 1 time. But that .ttc cache file would need to be read from the disk for each request and stored in memory. 

"/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/acqui/neworderempty.tt" has 721 lines and has a cached template of "/var/cache/koha/INSTANCE/templates/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/acqui/neworderempty.tt.ttc" which is 102KB. 

"/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/includes/circ-search.inc" has 43 lines and a cached template of /var/cache/koha/INSTANCE/templates/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/includes/circ-search.inc.ttc which is 4.6KB. 

But without actual response time metrics, those numbers aren't very helpful.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Julian Maurice
Sent: Wednesday, 15 July 2020 6:46 PM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] An idea for consolidating staff interface header search forms

I'm personally not a big fan of the "single big file" approach. I find it difficult to navigate through, and can cause git conflicts more often.
Also, it means that all blocks need to be parsed by TT on every page. 
Maybe it doesn't affect performance too much (or maybe it affects performance in a good way), but it makes more sense to me to only include what's needed.

I'd try to use WRAPPER + PROCESS directives to achieve the same thing:

[%# acq-searches.inc %]
[% WRAPPER 'header.inc' %]
   [% PROCESS 'vendor-search.inc' %]
   [% PROCESS 'orders-search.inc' %]
[% END %]

[%# header.inc %]
[% search_tabs = [] %]
<header>
   <div id="header_search">
     [% content %]
   </div>
   <ul>
     [% FOREACH tab IN search_tabs %]
       <li>[% tab %]</li>
     [% END %]
   </ul>
</header>

[%# vendor-search.inc %]
<form>...</form>
[% search_tabs.push('Search vendors') %]

Not sure if it works or if it is better than your solution, I just thought about that while reading your code. It probably has downsides too.


Le 14/07/2020 à 02:58, Owen Leonard a écrit :
>> this looks good to me - why do you think it might not be worth pursuing?
> No particular reason, I just wanted to get some opinions in case there
> was a downside I wasn't seeing.

-- 
Julian Maurice
BibLibre
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
https://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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200716/8b817845/attachment.sig>