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

[EP-tech] Re: About compounds

It's true - in fact authors ("creators", "editors"...) should probably 
point to a separate dataset and you could then use the modal thing I've 

But! Given how "creators" is hard-coded all over EPrints, you'll need to 
rewrite big chunks of the core for this to work nicely.

I think the compromise solution is to use the "id" bit (so creators_id) 
as a reference to another table. That other table can contain extra data 
that describes the author.

The danger with adding too many sub-fields is that you're creating an 
extra table per sub-field in the DB and as you've noticed, Gilles, this 
won't work on workflow/submission form.


On 08/07/14 16:14, John Salter wrote:
> I think that something that Seb demoed at the Eprints user group recently might be useful in this scenario...
> *if* you had an author dataset, (similar to the 'user' dataset), you could store authors as dataobjrefs.
> Seb's demo showed something similar for Projects/Funders - using a pop-up/modal window. It was very nice!
> There has been previous discussion around the subject of richer data for authors - but I can?t remember any definite endpoint to those discussions!
> Cheers,
> John
> -----Original Message-----
> From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Ian Stuart
> Sent: 08 July 2014 16:04
> To: eprints-tech at ecs.soton.ac.uk
> Subject: [EP-tech] Re: About compounds
> On 08/07/14 15:54, Gilles Fourni? wrote:
>> Hi,
>> The library staff wants us to describe authors with many fields
>> (internal id number, department, unit, ...).
>> So we wonder if we can add subfields to existing compounds like creators
>> or editors.
>> Obviously, we would keep existing subfields unchanged and just add new
>> subfields.
>> Is it safe to do so ? Or are there risks to break something ?
> Yes, adding extra fields is easy..... but only 1 level deep!
>> And, as a side question, I fear that a too big compound will be unusable
>> : in the input form, we will get a table with many columns, which will
>> probably be larger than the screen width. Is there a way to have the
>> subfields use several rows ?
> I've not seen one.... not without writing your own rendering routines
> (which are eminently doable..)