Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

BibEdit: consider adding alternative Javascript-less, basic, BibEdit #342

Closed
jeromecaffaro opened this Issue · 6 comments

6 participants

@jeromecaffaro
Collaborator

Originally on 2010-11-11

The editing of large records (~10'000 subfields) with BibEdit can be slow on some machines, due to the intensive use of Javascript. As a workaround, for simple editing of large records it might be useful to offer BibEdit users an alternative, which could simply consist in a showing the MARC or MARCXML representation of the record.</p> <p>This Javascript-less version would be ultra-fast, and with plugins such as <a href="http://mozex.mozdev.org/">MozEx</a> would let users edit the record in their preferred editor.</p> <p>A downside of this solution is the possibility for users to produce invalid markup if not used with caution. Server-side validation should be implemented. Another disadvantage over the current BibEdit is the loss of some neat Javascript-based features such as auto-complete.</p> <p>A possible implementation could simply show authorized users an "Edit" button on detailed record pages (<a href="http://invenio-demo.cern.ch/record/96/export/hm">http://invenio-demo.cern.ch/record/96/export/hm</a>), transforming the "HTML MARC" view into a textarea when clicked, with a possibility to apply changes. This could be extended to search results pages when viewed in HM output format <a href="http://invenio-demo.cern.ch/search?of=hm">http://invenio-demo.cern.ch/search?of=hm</a> .</p> <p>Some Javascript could still be used to enhance the user experience (for eg. ensure that tags shown in the left "column" of MARC output are not editable, or at least valid, or make sure that text selection is limited to content, not tags, similarly to what is done with source code syntax highlighting scripts on web pages <a href="http://codemirror.net/">http://codemirror.net/</a> <a href="http://www.cdolivet.com/editarea/editarea/exemples/exemple_full.html">http://www.cdolivet.com/editarea/editarea/exemples/exemple_full.html</a>) but then speed would surely again become an issue.</p> <p>Note the similarity with BatchUploader, which does rely on uploaded files instead. </p>

@invenio-developers
Collaborator

Originally by arwagner on 2010-11-12

I think offering a simple textarea also has some other benefits beyond the ability to work with large records. Just remember you have to copy a bunch of fields from one record to the other. (A new edition of some existing book comes to mind immediately or copies of indexing or classification terms and stuff).

For the contents of this textarea I'd strongly vote for MARC. Not marcxml. XML is way to "chatty" for a cataloguer all those tags floating around, simple Marc is way easier to read and edit.

Depending on usage I admit that in many areas of my daily work (subject indexing, currently we're using ) I would be way better off with a simple text area where I could insert MARC right away instead of this fielded kind of editing. As always: fielded editing is easier for the beginner, free editing way faster for those used to it. Therefore, depending on the kind of user, I think a "real cataloguer" might very well appreciate to edit plain MARC instead of adding fields and mouse clicking all the time. Just as it is way faster if you know your tags. (If you really doubt that, this kind of interface is default in all PICA installations, so default in more than the better half of Germany. I'd really like to have that back...)

@ppiotr
Collaborator

Originally on 2010-11-12

This use-case is served at the moment. Current version of BibEdit allows copying and pasting sets of MARC fields between records.

If the browser is configured in a way that gives to BibEdit access to the system clipboard, it is possible to copy-paste MARC XML between any text editor or other application and BibEdit. Supporting MARC instead of MARC XML would be a simple improvement.

This would not solve the performance issues ad BibEdit would have to be loaded anyway, but also providing an input box giving access to MARC (and later feeding the input back to BE), would not be difficult.

@jeromecaffaro
Collaborator

Originally on 2010-11-12

Switching from BibEdit to MARC back and forth would be nice, but it would probably still be needed that records can be saved by skipping the BibEdit internal representation of records: cataloguers have indeed experienced slow saving of records (after the editing phase).</p>

@tiborsimko
Owner

Originally on 2010-11-12

@ppraczyk: I had mentioned the current BibEdit MARCXML copy/paste capabilities to Jerome. This is very useful for one set of use cases. (BTW you had mentioned in the past that people have to tweak their browser security settings to allow cross-platform copy/paste; we should probably document it in the BibEdit Admin Guide somewhere.) However, an alternative textarea way of doing things would be very useful for other set of use cases. I think both can co-exist. Modulo record locking that has to be in common; probably best done via forthcoming record quarantine capabilities developed by Pablo.

@arwagner: BTW, note that powerful users can use CLI, if they have access to CLI.
Kind of like:

$ bibedit --list-revisions 1234567
1234567.20100124202721
1234567.20100123064941
1234567.20100122190313
1234567.20100122184901
$ bibedit --get-revision 1234567.20100122190313 > /tmp/z.xml
$ emacsclient /tmp/z.xml
$ bibupload -r /tmp/z.xml

Jerome's proposal makes this easier and quicker. BTW, I fully agree about MARC vs MARCXML, we can easily support both.

@traviscb
Collaborator

Originally on 2010-11-12

Replying to [comment:4 simko]:

@arwagner: BTW, note that powerful users can use CLI, if they have access to CLI.
Kind of like:

I also agree about MARC v XML, I also note that at SLAC we've some nascent work that we are calling "CLI" which is just a collection of useful imports and a few syntactic sugars for use in python interactive sessions. I like the Ipython REPL, and designing something for power users/admins to make changes at this level seems like one alternate way to address this need. Right now we are just saving off useful things as we need them, but a little more thought could go into it to make it a useful interface.

Travis

@jmartinm jmartinm closed this
@jmartinm
Collaborator

Originally on 2013-09-04

Commit in master:

47ea521 BibEdit: introduce textmarc editor

Introduces a simple text-based marc editor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.