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

[EP-tech] Re: About compounds

Thank you all for your advice.
I'll try your suggestions.

Have a nice day.

Le 08/07/2014 17:19, Sebastien Francois a ?crit :
> 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
> demo'ed.
> 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.
> Seb.
> 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..)
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/
> *** EPrints developers Forum: http://forum.eprints.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20140709/406e74c2/attachment.html