Open david-caro opened 7 years ago
I don't think templates should be moved. https://github.com/inveniosoftware-contrib/invenio-workflows-ui acts like the rest of invenio-foo-ui
packages which is basically handling the main views and maybe permissions (with sample templates)
Templates are in the overlay and that eases development and finding where things are in the codebase.
Templates are in the overlay and that eases development and finding where things are in the codebase.
We could have both by continuing the submodules
thing you started for inspirehep-search-js
: code is neatly separated in repos, but you can grep easily the codebase as long as you checkout the submodules locally.
(If you remember there was a speed talk at dotScale about this approach: https://www.youtube.com/watch?v=ZVsDA6GhKOU.)
We could have both by continuing the submodules thing you started for inspirehep-search-js: code is neatly separated in repos, but you can grep easily the codebase as long as you checkout the submodules locally.
Right, I still think the disadvantage of having things spread out in inveniosoftware
, inveniosoftware-contrib
and inspirehep
outweighs the benefits of testability and neat separation.
I am kind of ok with separating core packages that need to be reused and do not change often but when it comes to data model specific (such as templates) it is way more convenient to have in inspire-next
.
@david-caro I have amended title/description to clarify more the task to be done.
👍
Workflow templates (in https://github.com/inspirehep/inspire-next/tree/master/inspirehep/modules/workflows/static/js/inspire_workflows_ui/templates) need to be revised to make sure there is a clear division of templates for each type of workflow.
For example, details.html has become too big and contains logic for both
hep
andauthors
. Would be better if that template just had aswitch
statement to distinguish the workflow type and then render the appropriate template.Same logic should be applied for the other templates.