Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheme Label Editor & Reference Datatype Widget #169

Merged
merged 42 commits into from
Jan 17, 2025

Conversation

johnatawnclementawn
Copy link
Member

@johnatawnclementawn johnatawnclementawn commented Dec 31, 2024

Resolves #147

Requires Arches References #58

@johnatawnclementawn johnatawnclementawn linked an issue Dec 31, 2024 that may be closed by this pull request
Copy link
Contributor

@chrabyrd chrabyrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Just some pretty minor stuff -- happy to chat about about any of it

@aarongundel aarongundel force-pushed the adg/146-scheme-names branch 2 times, most recently from 3f68847 to fa5dc08 Compare January 3, 2025 17:16
Base automatically changed from adg/146-scheme-names to main January 3, 2025 17:16
@johnatawnclementawn johnatawnclementawn force-pushed the jmc/147_scheme_label_editor branch from 10b4718 to 7e3d631 Compare January 3, 2025 20:24
@johnatawnclementawn johnatawnclementawn marked this pull request as ready for review January 8, 2025 16:04
Copy link
Contributor

@chrabyrd chrabyrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

Copy link
Contributor

@chrabyrd chrabyrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops, was only looking at a subset of changes. One moment 😅

Copy link
Contributor

@chrabyrd chrabyrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code looks good but there's some functionality issues:

  • the dropdowns do not work for a new scheme label

Copy link
Member

@jacobtylerwalls jacobtylerwalls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking great!

arches_lingo/urls.py Outdated Show resolved Hide resolved
arches_lingo/templates/arches_urls.htm Outdated Show resolved Hide resolved
arches_lingo/src/arches_lingo/types.ts Outdated Show resolved Hide resolved
arches_lingo/src/arches_lingo/types.ts Show resolved Hide resolved
@robgaston
Copy link
Member

I'm noticing that the tables for Labels and Statements appear to have regressed on this branch, on main I see type and language:
Screenshot 2025-01-08 at 12 14 40 PM
but on this branch they do not appear in the table:
Screenshot 2025-01-08 at 12 13 22 PM

@johnatawnclementawn johnatawnclementawn force-pushed the jmc/147_scheme_label_editor branch from b03e64d to c290ff6 Compare January 8, 2025 20:23
Comment on lines 65 to 68
resource_instance_id = self.instance.resourceinstance.pk
resource_instance = self.instance.resourceinstance.__class__.as_model(
graph_slug, resource_ids=[resource_instance_id]
).get(pk=resource_instance_id)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm looking into adding a developer convenience for this, either a method .enrich() and/or overwriting the .resourceinstance descriptor on the TileQuerySet so that it's a lazy getter that calls enrich() for you. 👀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Not suggesting to block this PR on it.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jacobtylerwalls I swear this was working yesterday, but when I try to create a new label for an existing scheme self.instance is None. Would you be able to take a look at that in my absence?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! I think you and I were only testing updates, not creates. I also added a little developer convenience for now.

Copy link
Contributor

@chrabyrd chrabyrd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall code looks good, some minor non-blocking nits there.

I'm noticing that I still can't add new labels, and the dropdowns powering the editor still do not show their selection if creating a new label.

Also I'm noticing this warning in the console now:

runtime-core.esm-bundler.js:202 [Vue warn]: Extraneous non-props attributes (pt) were passed to component but could not be automatically inherited because component renders fragment or text root nodes. 
  at <ReferenceDatatypeEditor value=null options= [{…}] multi-value=false  ... > 
  at <ReferenceDatatype value=null mode="edit" multi-value=false  ... > 
  at <LabelEditor value= {tileid: '7b559cf4-77a1-49b3-9116-aabffd464bd3', resourceinstance: 'b73e741b-46da-496c-8960-55cc1007bec4', nodegroup_id: 'ef87ac28-11de-11ef-9493-0a58a9feac02', sortorder: 0, provisionaledits: null, …} onUpdate=fn<update> > 
  at <SchemeLabel mode="edit" tileId="7b559cf4-77a1-49b3-9116-aabffd464bd3" onUpdated=fn<onSectionUpdate>  ... > 
  at <SchemeEditor key=0 editor-max=true editor-form="label"  ... > 
  at <SplitterPanel key=1 size=33 min-size=33  ... > 
  at <Splitter style= {height: '100%'} > 
  at <SchemePage onVnodeUnmounted=fn<onVnodeUnmounted> ref=Ref< Proxy(Object) {__v_skip: true} > > 
  at <RouterView> 
  at <SplitterPanel min-size=25 style= {overflow-y: 'auto'} tabindex="-1" > 
  at <Splitter style= {height: '100%', overflow: 'hidden'} pt= {gutter: {…}} > 
   at <HierarchySplitter key=0 > 
  at <App>

but if these are planned to be addressed in followup tickets, I won't block.

@@ -10,6 +10,7 @@ const props = withDefaults(
defineProps<{
val?: string[];
options?: ResourceInstanceReference[];
ptAriaLabeledBy?: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems this shouldn't be an optional prop?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be optional because there are other ways of ensuring your forms are accessible and I don't think we should force use of aria labeled by

const props = defineProps<{ value: string }>();
const props = defineProps<{
value: string;
ptId?: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

naming nit? what is a ptId?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Primevue InputText doesn't take an ariaLabeledBy prop like some of their other components, so instead I gave that component an Id, hence pass-through Id (ptId). Fixed in latest, but if we start to use these pass-throughs a lot more, I think pt as an object (pattern that primevue uses) is better than this.

Comment on lines 72 to 73
label_language = label.appellative_status_ascribed_name_language[0]
label_type = label.appellative_status_ascribed_relation[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These fail with KeyError if not provided. If these fields are truly required at the node config level (seems like a model issue that they aren't) then the arches queryset layer that handles the tile validation logic will reject it. But since that layer is later, this layer needs to be a little more forgiving.

Unless!

We "override" the fields in this serializer to enforce that they're required at the outermost layer. Something like:

diff --git a/arches_lingo/serializers.py b/arches_lingo/serializers.py
index 1017492..db61b2b 100644
--- a/arches_lingo/serializers.py
+++ b/arches_lingo/serializers.py
@@ -1,3 +1,4 @@
+from rest_framework import serializers
 from rest_framework.exceptions import ValidationError
 
 from arches_references.models import ListItem
@@ -47,6 +48,10 @@ class SchemeLabelSerializer(ArchesModelSerializer):
 
 
 class SchemeLabelTileSerializer(ArchesTileSerializer):
+    # Get this from a mapping from datatypes to serializer fields
+    # then add required=True to fail faster
+    appellative_status_ascribed_name_language = serializers.JSONField(allow_null=True, required=True)
+
     class Meta:
         model = TileModel
         graph_slug = "scheme"

If we do that, then your business logic doesn't need to guard against missing values, because we fail before getting here (Looks like we need to improve the error toast to actually return the error message from the server keyed on field name instead of just "Bad Request".)

Nice to have some options here. I'm not convinced overriding the serializer field is better; it's probably easier to just fix your [0] 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a fix for this, but we probably want a dataclass or something to prevent this awkward double fallback.

def validate(self, data):
data = super().validate(data)
graph_slug = self.Meta.graph_slug
PREF_LABEL_LIST_ITEM = ListItem.objects.get(list_item_values__value="prefLabel")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to catch MultipleObjectsReturned or otherwise define which list item wins.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed an update for this, a bit silly, but there are probably better things we can do in the future around identifying a list with a natural key (should name be unique, assuming it's not localized?)

Comment on lines 65 to 68
resource_instance_id = self.instance.resourceinstance.pk
resource_instance = self.instance.resourceinstance.__class__.as_model(
graph_slug, resource_ids=[resource_instance_id]
).get(pk=resource_instance_id)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! I think you and I were only testing updates, not creates. I also added a little developer convenience for now.

and label_language["uri"] == new_label_language["uri"]
):
raise ValidationError(
"A preferred label with the same language already exists for this scheme."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I localized this and borrowed the wording from arches-references to prevent creating a second translatable string.

const router = useRouter();
const selectedLanguage = inject(selectedLanguageKey) as Ref<Language>;
const { $gettext } = useGettext();
const formId = (route.params.id as string) ?? Math.random().toString();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL that Vue 3.5 ships a useId() hook for this: https://vuejs.org/api/composition-api-helpers.html#useid

That's likely better than rolling our own.

Also: why wouldn't we put this label inside the <DateDatatypeEditor> and perhaps use <label for= like you had before, instead of passing this down through all these layers?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed an update to use this

@jacobtylerwalls jacobtylerwalls self-assigned this Jan 17, 2025
@jacobtylerwalls
Copy link
Member

I'm noticing that I still can't add new labels, and the dropdowns powering the editor still do not show their selection if creating a new label.

I fixed this by reverting the revert @johnatawnclementawn added after the demo. Johnathan, let me know if there's a reason you wanted to revert and let's discuss 👍

Also I'm noticing this warning in the console now

Fixed in 35a1237

@jacobtylerwalls jacobtylerwalls merged commit ed3b0ca into main Jan 17, 2025
4 checks passed
@jacobtylerwalls jacobtylerwalls deleted the jmc/147_scheme_label_editor branch January 17, 2025 23:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Scheme Labels Form/Editor
4 participants