[Question] Why is the dependency to slub_digitalcollections needed?

[csidirop]

A general question: why do we need the dependency on slub_digitalcollections? Wouldn't it be possible to include these few in the DFG-Viewer?

This would make troubleshooting and maintenance much easier. I came across this question / suggestion because I find multiple of the html pages in presentation, DFG-Viewer and slub_digitalcollections and wonder if this repetitiveness is necessary.

If the idea is well received, I would also like to help separate DFG-Viewer from slub_digitalcollections.

[sebastian-meyer]

I think this was just a pragmatic decision to reuse configuration and templates without duplicating files.

But I am with you, so +1 for getting rid of this dependency! ;o)

[beatrycze-volk]

I also find it as a good idea :)

[MarcMoschSLUB]

The proposed solution creates additional maintenance effords. Before we take this path, we need to assess the impact of this decision.

[csidirop]

What additional maintenance efforts are you thinking of? Because I think that the current situation is slowing down development.

Maybe you can explain to me what the original idea behind it was.

[MarcMoschSLUB]

Bugfixing and feature development (in view helpers, templates etc.) would have to be done in two different places (digitalcollections and dfg-viewer) with your proposal.

This goes against the initial intention to reduce duplicated code.

What are the benefits that in your eyes outweight this drawback?

[csidirop]

Bugfixing and feature development (in view helpers, templates etc.) would have to be done in two different places (digitalcollections and dfg-viewer) with your proposal.

But if we can get rid of the digitalcollections it don't need to be done in two places. And if you want to customize your view helpers, templates and so on for your presentation you can still do it. It should be optional, with optional additions for our institution.

Lets say you have an other or better approach for an template, than update it in the dfg-viewer. If you think that its just for your especial case needed in SLUB, than you can still use your digitalcollections or just your own branch.

No drawback from my site of view. Or have I misunderstood why the slub_digitalcollections exist at all?

This goes against the initial intention to reduce duplicated code.

But we actually have duplicated code the way it is.

What are the benefits that in your eyes outweight this drawback?

Like I said, reducing the complexity should reduce the effort needed to develop and maintain the dfg-viewer and even presentation if used together. Especially for developers who do not have an overview of the repos and how they interact with each other.
For us it was often unclear when which template, less/css or js was used.

Last, not needing to have a second repository actively maintained, at least in the same intensity as presentation and dfg-viewer is, should be a major benefit on your side, or? For us it means, that maintenance PR are not sitting there for weeks.

Excuse me if I'm missing something and getting it wrong.

[csidirop]

Hi @MarcMoschSLUB, have you any thoughts on this?

[MarcMoschSLUB]

Thank you for your valueable input and sorry for the late answer
You are right with many of your assumptions. But that's something we don't want to handle ad hoc without knowing all dependencies and consequences. We need to find the time to analyse and plan before we start to make such a fundamental change.

[csidirop]

Okay, take your time.
I have already prepared a draft and will update it when I have spare time.