[Koha-bugs] [Bug 4447] New: Allow external URL/storage location for XSLT stylesheets

bugzilla-daemon at kohaorg.ec2.liblime.com bugzilla-daemon at kohaorg.ec2.liblime.com
Tue May 4 17:46:40 CEST 2010


http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4447

           Summary: Allow external URL/storage location for XSLT stylesheets
           Product: Koha
           Version: HEAD
          Platform: PC
        OS/Version: Windows 2000
            Status: ASSIGNED
          Severity: enhancement
          Priority: P5
         Component: OPAC
        AssignedTo: jwagner at ptfs.com
        ReportedBy: jwagner at ptfs.com
   Estimated Hours: 0.0
 Change sponsored?: ---


I'd like some feedback on this before proceeding.  One of the most frequent
customization requests I get is to display this or that MARC field or subfield
in the OPAC.  Usually this would have to be done by customizing the relevant
XSLT stylesheet (MARC21slim2OPACResults.xsl and MARC21slim2OPACDetail.xsl are
the two I usually work with.  However, for sites where access to the server
level is restricted or where local customizations are not allowed, this won't
work.  I'm thinking of creating a syspref to allow a site to specify a remote
server location for the XSLT stylesheets.  That way, sites could maintain and
modify a file with local customizations, without requiring any server access.

Trying to analyze the code in XSLT.pm, it looks like I could only allow
specifying a path, not a filename.  Both details and results files would have
to be in place on the remote server, and retain the identical filenames as
currently used.

Right now, I'm only looking at OPAC XSLT, but the same logic could be extended
to staff XSLT files as well.  I think they would have to be stored in the same
location as the OPAC ones, so maybe only one syspref should be created for
both.

Discussion?  Potential problems?


-- 
Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the Koha-bugs mailing list