koha-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Koha-devel] MARC Editor Visibility


From: Joshua Ferraro
Subject: [Koha-devel] MARC Editor Visibility
Date: Thu, 23 Mar 2006 13:11:34 -0800
User-agent: Mutt/1.4.1i

Hi all,

thd and I have introduced some additional complexity into the
MARC frameworks that offers a more complete handling of tag
and subfield visibility. It's completely backwards-compatible
so if you're happy with your current visibility options you
don't need to do a thing and everything will behave exactly
as it did before.

First, I should introduce the problem: with the old scheme,
there was a flag (INT(1)) that allowed hiding a subfield in
the OPAC. You could also set a subfield to 'ignored' which was
used for the special tags/subfields whose values are managed
internally (e.g., 090). This would probably have sufficed
but for the fact that thd has been working on a complete
'Standard MARC21 Framework'. In testing this framework
(which includes 2/3s more fields than 2.2.5's default
framework), we discovered that it was unusable due to long
page loads (it's really quite a huge form with about
3,500 fields defined). (just to give you an idea of how
slow it was, it took about 90 seconds to load a blank
'addbiblio' page and about 2-3 minutes to save a populated
record).

In addition, there is the problem of usability. With so many
tags and subfields on a page it's very difficult to identify
the most commonly used fields -- they are lost among the
uncommon and rare fields.

So we set out designing a 'visibility scheme' with three
basic goals:

1. prevent very rare tags/subfields from being loaded into the
        MARC editor by default, but allow the user to add them
        if needed (with a page reload) and _definitely_ load
        them if they already exist in a record (ie, _no_ data
        lost when using the MARC editor).

2. allow uncommonly used fields to be collapsed and expanded
        quickly and easily without a page reload.

3. preserve the legacy 'hidden' functionality so the new
        framework isn't required for the upgrade to 2.2.6.

As it turns out, there are quite a few possible visibility
conditions that should be properly dealt with in a future
version of Koha. Using the current framework's 'hidden'
database definition (INT(1)) we can account for up to 19
such conditions (values -9 thru 9). Given that limitation
as well as our current time constraint, we identified 17
conditions that will be defined in the new 'Standard MARC21
Framework' plus a 'Flag' condition that can be used to flag
subfield definitions that will need to be revised when the
framework can handle more conditions (ie, in 3.0). The
scheme we devised is the following:

( ! means 'not visible' or in the case of Collapsed 'not
Collapsed')


  -9 => Future use
  -8 =>  Flag
  -7 =>  OPAC !Intranet !Editor  Collapsed
  -6 =>  OPAC  Intranet !Editor !Collapsed
  -5 =>  OPAC  Intranet !Editor  Collapsed
  -4 =>  OPAC !Intranet !Editor !Collapsed
  -3 =>  OPAC !Intranet  Editor  Collapsed
  -2 =>  OPAC !Intranet  Editor !Collapsed
  -1 =>  OPAC  Intranet  Editor  Collapsed
   0 =>  OPAC  Intranet  Editor !Collapsed
   1 => !OPAC  Intranet  Editor  Collapsed
   2 => !OPAC !Intranet  Editor !Collapsed
   3 => !OPAC !Intranet  Editor  Collapsed
   4 => !OPAC  Intranet  Editor !Collapsed
   5 => !OPAC !Intranet !Editor  Collapsed
   6 => !OPAC  Intranet !Editor !Collapsed
   7 => !OPAC  Intranet !Editor  Collapsed
   8 => !OPAC !Intranet !Editor !Collapsed
   9 => Future use

With this scheme, it's quite simple to check for the most
important cases:

*if (odd) { collapsed }
*if (even) { !collapsed }
if (>=0) { hidden in OPAC }
if ((<=-4)||(>=5)) { not in the editor unless exists or is added}

Those four checks take care of all the goals we set out
to achieve. Of course, there are finer distinctions to be made,
but we'll leave that for a future version. So just to clarify,
we've implemented a subset of the scheme we devised --
a subset that doesn't comprimise where it counts (ie there won't
be any data loss as with Koha 2.2.5).

If you want to try out the new system feel free to use LibLime's
demo:

http://koha.liblime.com/cgi-bin/koha/acqui.simple/addbiblio.pl

You'll notice that some tags (take 040 as an example) are
listed but the subfields within them aren't -- simply click
on the little + graphic to expand the fields (no page load)

Likewise, some very rare tags/subfields don't appear by default.
However, if you do a Z3950 search for a record and one contains
them they will appear when you import the record (they will also
import if they exist in records in the database).

Cheers,

-- 
Joshua Ferraro               VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE
President, Technology       migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS




reply via email to

[Prev in Thread] Current Thread [Next in Thread]