Deprecating the Non-XSLT display on Detail and Search/List Results
Hi folks: What do people think about deprecating the non-XSLT display on detail and search/list results pages? The XSLT display provides more data in a much more attractive way than the non-XSLT templates. They're also easier to maintain (as you don't need to modify the Perl scripts to feed data forward). We already have default XSLTs so it would be trivial to use these as fallbacks where people haven't specified a XSLT with the global system preferences. Going forward, I much rather maintain one set of templates than two. I don't know about the most recent versions, but in the past (e.g. 3.8) there were issues with the non-XSLT displays not showing data in the right order and not having as much data. Rather than update these displays, it seems much more logical to deprecate them and switch everyone to using the more modern templates. -David
Hi, On Wed, Apr 23, 2014 at 8:12 PM, David Cook <dcook@prosentient.com.au> wrote:
What do people think about deprecating the non-XSLT display on detail and search/list results pages?
0. Here follows some thinking aloud: One of the main advantages of the XSLT display templates is that they have full access to the entire metadata record, and as a consequence it's possible to put in complicated display logic without having to write custom Perl code. This mattered quite a bit at the time that XSLT display system was introduced because HTML::Template::Pro lacked good support for things like filters and template functions. Removing the non-XSLT templates would also make it possible to remove a fair amount of code for extracting data from MARC records, as that could be left to the XSLT templates. The big downside is that XSLT is not particularly user-friendly, particularly if you want to make changes that go beyond tweaking a couple labels. The verbosity of XSLT's syntax also can get in the way of developers wanting to make changes. However, the importance of that consideration depends on an answer to a question that I, for one, don't have a good sense of: how many Koha libraries actually make major changes to their OPAC record displays? Nowadays, if I were asked to put together a fresh set of OPAC templates for Koha, I would probably do it via Template Toolkit, but organized differently: the search results and bib details code would just pass along metadata (for now MARC::Record) and item objects to the template, and there would be a site of helper functions available for grabbing display values. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Hi all, i have never ever had an instance of Koha running with the non-xslt display. The few times i forgot to activate it gave catastrophic results, and i quickly put some stylesheets there. Maybe it's different in marc21. Our default xslt stylesheets do need a lot more work to get better actually (i am speaking for unimarc here). But it does seem to me like it is a better idea to do it in xslt rather than in the templates. (Because whatever we do there can be built upon by each library that uses Koha more easily. And because users could share what they do here like they do it for sql reports.) Best, Le 24/04/2014 05:12, David Cook a écrit :
Hi folks:
What do people think about deprecating the non-XSLT display on detail and search/list results pages?
The XSLT display provides more data in a much more attractive way than the non-XSLT templates. They're also easier to maintain (as you don't need to modify the Perl scripts to feed data forward). We already have default XSLTs so it would be trivial to use these as fallbacks where people haven't specified a XSLT with the global system preferences.
Going forward, I much rather maintain one set of templates than two. I don't know about the most recent versions, but in the past (e.g. 3.8) there were issues with the non-XSLT displays not showing data in the right order and not having as much data. Rather than update these displays, it seems much more logical to deprecate them and switch everyone to using the more modern templates.
-David
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.boisson@biblibre.com
+1 for deprecating non-XSLT. If a better (then XSLT) solution arises it won't have to do with the old non-XSLT code and templates. Regards To+ On Thu, Apr 24, 2014 at 12:12 AM, David Cook <dcook@prosentient.com.au>wrote:
Hi folks:
What do people think about deprecating the non-XSLT display on detail and search/list results pages?
The XSLT display provides more data in a much more attractive way than the non-XSLT templates. They’re also easier to maintain (as you don’t need to modify the Perl scripts to feed data forward). We already have default XSLTs so it would be trivial to use these as fallbacks where people haven’t specified a XSLT with the global system preferences.
Going forward, I much rather maintain one set of templates than two. I don’t know about the most recent versions, but in the past (e.g. 3.8) there were issues with the non-XSLT displays not showing data in the right order and not having as much data. Rather than update these displays, it seems much more logical to deprecate them and switch everyone to using the more modern templates.
-David
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 4333190 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
+1 for less dead code Le 24/04/2014 05:12, David Cook a écrit :
Hi folks:
What do people think about deprecating the non-XSLT display on detail and search/list results pages?
The XSLT display provides more data in a much more attractive way than the non-XSLT templates. They're also easier to maintain (as you don't need to modify the Perl scripts to feed data forward). We already have default XSLTs so it would be trivial to use these as fallbacks where people haven't specified a XSLT with the global system preferences.
Going forward, I much rather maintain one set of templates than two. I don't know about the most recent versions, but in the past (e.g. 3.8) there were issues with the non-XSLT displays not showing data in the right order and not having as much data. Rather than update these displays, it seems much more logical to deprecate them and switch everyone to using the more modern templates.
-David
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers@biblibre.com
On 24 April 2014 05:12, David Cook <dcook@prosentient.com.au> wrote:
What do people think about deprecating the non-XSLT display on detail and search/list results pages?
+1. I'm not overly fond of XSLT as such, but reducing complexity is good. Best regards, Magnus
Hi, On Tue, Apr 29, 2014 at 12:40 AM, Magnus Enger <magnus@enger.priv.no> wrote:
On 24 April 2014 05:12, David Cook <dcook@prosentient.com.au> wrote:
What do people think about deprecating the non-XSLT display on detail and search/list results pages?
+1.
I'm not overly fond of XSLT as such, but reducing complexity is good.
I really want to hear from current users on this one. I've sent out a tweet, but I suggest that somebody who is strongly in favor of the deprecation also raise the question on the mailing list -- in particular, whether there are folks who intentionally do not use the XSLT option. If the consensus is to announce a deprecation, we may as well do so upon the release of 3.16.0. Of course, because of bug 10134, somebody who started with 3.12.0 or later would have had to intentionally turn the XSLT option off. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
I tried to compare the load time difference between the 2 views: 1/ OPACXSLTDetailsDisplay empty for i in {1..10}; wget "http://opac.koha.vm/cgi-bin/koha/opac-search.pl?q=d" 2/ OPACXSLTDetailsDisplay set to default for i in {1..10}; wget "http://opac.koha.vm/cgi-bin/koha/opac-search.pl?q=d" Retrieve the time from the Apache access log: sum_empty=`tail -n 20 koha-opac-access.log | head -n 10 | sed 's/.*time=\(.*\)/\1/g' | tr -s "\n" "+"`"0"; echo $sum_empty | bc sum_default=`tail -n 10 koha-opac-access.log | sed 's/.*time=\(.*\)/\1/g' | tr -s "\n" "+"`"0"; echo $sum_default | bc And I got the same values: 11812116 vs 11800376 ~ 1.1s per page loaded I expected a more important load time with XSLT enabled. 2014-04-29 21:29 GMT+02:00 Galen Charlton <gmc@esilibrary.com>:
Hi,
On Tue, Apr 29, 2014 at 12:40 AM, Magnus Enger <magnus@enger.priv.no> wrote:
On 24 April 2014 05:12, David Cook <dcook@prosentient.com.au> wrote:
What do people think about deprecating the non-XSLT display on detail and search/list results pages?
+1.
I'm not overly fond of XSLT as such, but reducing complexity is good.
I really want to hear from current users on this one.
I've sent out a tweet, but I suggest that somebody who is strongly in favor of the deprecation also raise the question on the mailing list -- in particular, whether there are folks who intentionally do not use the XSLT option. If the consensus is to announce a deprecation, we may as well do so upon the release of 3.16.0.
Of course, because of bug 10134, somebody who started with 3.12.0 or later would have had to intentionally turn the XSLT option off.
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
participants (8)
-
David Cook -
Fridolin SOMERS -
Gaetan Boisson -
Galen Charlton -
Jonathan Druart -
Magnus Enger -
Mason James -
Tomas Cohen Arazi