EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #00532


< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Re: New Import Screens


On Wed, 2012-05-09 at 14:31 +0000, Berry, Rob wrote:
> I'm currently developing a plug in to allow the user to search the
>  Scopus/SciVerse API for documents, then directly import the metadata
>  into their EPrints.
> 
> It's nearly done, but as this works differently from normal plug ins -
>  not importing via a textbox or file, but rather selecting items that
>  are loaded using JavaScript - I've had to use a screen plug in as well
>  as an import plug in. But the import screen is not available from the
>  'Import from' dropdown list, which would be ideal.
> 
> At the moment I'm considering making another plug in to add the
>  functionality of being able to create Import screens (through
>  overwriting functions in the core files), which would automatically
>  appear in this list. This is not ideal as I know it could easily be
>  broken with future updates of EPrints. So I'm writing here to ask if
>  you have any recommendations or alternatives before I begin? 

Hi,

I'm making substantial changes to the Import screen to support
interactive imports e.g.
http://trac.eprints.org/eprints/browser/trunk/system/perl_lib/EPrints/Plugin/Import/ISIWoK.pm

I've not finalised the API but the idea is this:
 - Import plugins can do any of 1) free-text input, 2) file-upload
input, 3) HTML form input.
 - Import data is converted into epdata and stored in a cache table
 - User can select from the available objects to import individually or
"import all"

The responsibility of the Import plugin is to query the remote service
(optionally with a record offset), convert the resulting records into
epdata and tell the Import screen the total number of records.


At the moment it's a bit of a kludge because the existing import assumed
that the import would be a one-shot process (vs. interactively querying
a remote service) and would only import into one dataset.

But anyway ... you may want to work on the trunk version of EPrints,
then think about how to back-port.

-- 
All the best,
Tim

Attachment: signature.asc
Description: This is a digitally signed message part