I've taken another look at the xslt, specifically for the OPAC search
results. The 245$b is already displayed by the stylesheet, but the item
call numbers are not. This was the problem I couldn't solve the first
time I looked at the xslt.
Also it looks to me like the OPAC xslt will only show item availability
for the first branch that has an item. Maybe I'm understanding the xslt
wrong, but looking at a search result in the OPAC it seems this is true.
I'm looking at this bit in the OPAC stylesheet for MARC21:
<xsl:variable name="available_items"
select="key('item-by-status', 'available')"/>
<xsl:for-each
select="$available_items[generate-id() =
generate-id(key('item-by-status-and-branch', concat(items:status, ' ',
items:homebranch))[1])]">
: I don't see how that will grab more that just the first homebranch.
I would very much welcome any suggestions on getting item call numbers
into the xslt. I'd also welcome comments on the item availability
thing.
On Tue, 2008-12-02 at 10:40 -0500, Joshua Ferraro wrote:
> On Tue, Dec 2, 2008 at 10:37 AM, Michael Hafen <mdha...@tech.washk12.org>
> wrote:
> > On Mon, 2008-12-01 at 19:31 -0500, Joshua Ferraro wrote:
> >> On Mon, Dec 1, 2008 at 6:55 PM, Michael Hafen <mdha...@tech.washk12.org>
> >> wrote:
> >> > I looked at it briefly for a different field, and found my understanding
> >> > of XSL lacking. Adding a column to the database was the quick solution
> >> > for me.
> >> XSL would also solve the specific problem you have, just turn on those
> >> two sysprefs and walla ...
> >>
> >
> > Well, it's not actually that straight forward. I still have to learn
> > how to read and modify an XSLT stylesheet.
> It is if all you want to solve is 245$b ... that's already in the stylesheet.
>
> Cheers,
>
> Josh
> >> > I guess I can take another look. It might be a good solution. My
> >> > thinking is that it's good to see data from the two ( potentially
> >> > different ) copies of the record, what's in the database columns and
> >> > what's in the marcxml column. I'll have to look again at the XSL to see
> >> > where it comes from too.
> >> marcxml has a full MARCXML record blob representing the entire
> >> bibliographic and item information for that record. XSL has the
> >> advantage of being able to handle repeatable fields, wheras the
> >> current database design for Koha can only handle non-repeatable
> >> fields.
> >>
> >
> > It did occur to me that the database can only handle non-repeatable
> > fields. Luckily for me 245$b is non-repeatable in the Koha Default
> > Biblio Template. Still I think it would be possible to handle
> > repeatable fields, just concatenate the fields together with a
> > seperator, but the database columns would have to be very large to do it
> > right. That isn't really a good solution.
> >
> > At any rate I will take a look at the XSL files.
> >
> > This raises the question of how many others are interested in a patch to
> > this end. Ryan may want to comment here as he has already stated that
> > LibLime uses XSLT. Any others want to comment?
> >
> >> Josh
> >>
> >
> > --
> > Michael Hafen
> > Systems Analyst and Programmer
> > Washington County School District
> > Utah, USA
> >
> > for Koha checkout
> > http://koha-dev.washk12.org
> > or
> > git://koha-dev.washk12.org/koha
> >
> >
>
>
>
--
Michael Hafen
Systems Analyst and Programmer
Washington County School District
Utah, USA
for Koha checkout
http://koha-dev.washk12.org
or
git://koha-dev.washk12.org/koha
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel
