[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Koha-devel] MARC Editor Visibility
From: |
Joshua Ferraro |
Subject: |
Re: [Koha-devel] MARC Editor Visibility |
Date: |
Wed, 29 Mar 2006 09:50:50 -0800 |
User-agent: |
Mutt/1.4.1i |
On Mon, Mar 27, 2006 at 02:48:32PM +0200, Pierrick LE GALL wrote:
> Thank you for sending a clean explanation by mail, I didn't understand
> what you were talking about with thd and paul on IRC.
np
> I agree that in a general way, MARC Editor really need improvement. I
> bet the best improvement will be to use another technology than
> HTML/Javascript... (Paul's student will work on it I suppose).
Yep, in fact, there is a basic description of our goal here:
http://wiki.liblime.com/doku.php?id=catalogingproject
Paul's student will work on this, but also, an Ohio University class
will begin working on it in a couple of weeks. It would be nice
if we could figure out some way to collaborate all our resources
rather than reinvent the wheel each time.
> At this point, I thought you had found a way to /suggest/ which
> tags/subfields were rare and which were uncommon. (Wouldn't it be
> interesting?)
Yes, very. However, our scheme only allows us to specify which
should be visible in the editor based on the visibility flag in
the framework.
> > 3. [backward compatibility]
>
> So your technical solution is:
>
> > [...] Using the current framework's 'hidden' [...] Given that
> > limitation [...]:
Correct ... we are aiming for backwards-compatibility by not
changing the database at all (a requirement of 2.2.x releases).
> Joshua, I implore you to make this simpler on HEAD. If you need 4
> boolean values ($display_in_OPAC, $display_in_intranet,
> $show_in_editor, $collapse_in_editor), use 4 booleans. Not a 16
> values flag. It will be far more readable for the one who did not code
> the first version.
>
> The solution you propose is mind satisfaying but hard to
> understand and maintain for followers.
I agree 100%. When it comes time to discuss the marc framework in
HEAD we'll definitely be creating some new tables to store the
necessary data.
> Staying on the MARC editor topic, is there a kind of specification for
> the future MARC editor Koha needs in 3.0 ? (I mean the one that Paul's
> student is supposed to work on)
http://wiki.liblime.com/doku.php?id=catalogingproject
(also posted above)
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