relations form vertical scroll

[gythaogg]

This pull request includes updates to the CSS for the relation dialog and the addition of a new form in the sample_project application.

CSS updates:

• apis_core/relations/static/css/relations.css: Changed the overflow property of the #relationdialog to overflow-x: visible and overflow-y: scroll for better handling of content overflow.

Form additions:

• sample_project/forms.py: Added a new form class LivesInForm that inherits from RelationForm and includes a notes field with a large textarea widget.

[b1rger]

Thanks! That bug already annoyed me and we also have a bug report in oebl for that acdh-oeaw/apis-instance-oebl-pfp#354 !

I'm not sure if it is worth it to add the additional fields to the sample project, but that is definitely up for discussion. If we try to showcase every css fix in the sample project it will soon get overly complex and IIRC the idea of the sample_project was also for external users to have an easily understandable test project they can use to get to know APIS.
Especially in this case, the suggested change did not lead to the wanted showcasing of the bug, because my screen is big enough so that the added form fields also visible without the css fix.

An alternatative to the change of the models (which also bugs me a bit, because it changes the datamodel and adds migrations) would be to override the default form for a relation:

from django import forms
from apis_core.relations.forms import RelationForm


class LivesInForm(RelationForm):
    notes = forms.CharField(widget = forms.Textarea(attrs={"rows": "70"}), required=False)

Also: could you make the commit message a bit more verbose (I suppose the PR message was generated, but some of that information could be part of the commit message, i.e. "handle overflow separately for the x and y axes, making the y-axis scrollable").
"vertical scroll in relations dlg" is a bit scarce, maybe "handle overflow in relation dialog" and then in the message describe the problem and "handle overflow separately for the x and y axes, making the y-axis scrollable" from the PR description.

In general I think the commit message should be the primary source for information about the changes, not the PR description.

[gythaogg]

In general I think the commit message should be the primary source for information about the changes, not the PR description.

Yeah, that's fair. I never go and look at a PR description when I time travel to find when/why something changed .

[b1rger]

(added a comment to the form and wrote out "dialog" in the commit message)

[gythaogg]

(added a comment to the form and wrote out "dialog" in the commit message)

Damn - I had to shorten it because my editor said it was too long. I need to align the commit message linter config with my own