EPrints Technical Mailing List Archive
See the EPrints wiki for instructions on how to join this mailing list and related information.
Message: #08929
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
Re: [EP-tech] Eprint default template XML file
- To: Laurent Cloarec via Eprints-tech <eprints-tech@ecs.soton.ac.uk>
- Subject: Re: [EP-tech] Eprint default template XML file
- From: Christopher Gutteridge <totl@soton.ac.uk>
- Date: Fri, 13 May 2022 16:08:39 +0100
If I recall... the file is evaluated for the current context, resolving all the conditions based on the context item (eprint), and ending up with a set of stages, containing components, containing fields.
So long as that happens it'll work fine. However if you've
decided to put the logic at a higher level, that's fine. Just be
careful to make sure when you make a change you apply it to all
the relevant places it repeats that element.
On 13/05/2022 14:40, Laurent Cloarec
via Eprints-tech wrote:
CAUTION: This e-mail originated outside the University of Southampton.Hi everybody!
The "core" stage of the cfg/workflows/eprint/default.xml file for our repository had slowly become a "mess" (or, if you prefer a gastronomic metaphor, some kind of "plate of spaghetti"!), each time harder to maintain, with its huge amount of nested tests, loops, etc...
For instance, I've just figured out that two contradictory logical tests where nested one into the other!
So I would like to reorder it, and the first idea that comes to me is to use the following EPC tags, according to the type of item, somehow like this:
where the "..." dots would be replaced by the complete list of every "component" necessary for the given item type, with the required values tests.<epc:choose><epc:when test="type ='item_type_x'">...</epc:when><epc:when test="type ='item_type_y'">...</epc:when><epc:when test="type ='item_type_z'">...</epc:when><epc:otherwise>...</epc:otherwise></epc:choose>
But my question comes around the fact to wonder if it's a good idea, or if it is mandatory to follow the commonly ordered flow of all possible components, whatever the item type may be (tests would determine their presence or not).
Thank you in advance for any "authorized" answer, and best regards...
--
Laurent Cloarec
Service Commun de la Documentation - Service du Numérique Documentaire
Université Toulouse 1 Capitole
tél. : (+33)(0)5.34.45.61.23
*** 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/
-- Christopher Gutteridge <totl@soton.ac.uk> You should read our team blog at http://blog.soton.ac.uk/webteam/ (I live near Highfield Campus, so in person, outdoor and socially distanced meetings are an option)
- Follow-Ups:
- Re: [EP-tech] Eprint default template XML file
- From: Christopher Gutteridge <totl@soton.ac.uk>
- Re: [EP-tech] Eprint default template XML file
- References:
- [EP-tech] Eprint default template XML file
- From: Laurent Cloarec <Laurent.Cloarec@ut-capitole.fr>
- Re: [EP-tech] Eprint default template XML file
- From: Christopher Gutteridge <totl@soton.ac.uk>
- [EP-tech] Eprint default template XML file
- Prev by Date: [EP-tech] EPrints for Research Data services
- Next by Date: Re: [EP-tech] EPrints for Research Data services
- Previous by thread: [EP-tech] EPrints/CRIS
- Next by thread: [EP-tech] DOI handling in orcid_support_advance
- Index(es):