-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
There was a problem hiding this 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
arches_lingo/src/arches_lingo/components/generic/LabelEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/LabelEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/LabelEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/LabelEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/reference-datatype/ReferenceDatatypeEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/reference-datatype/ReferenceDatatypeEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/reference-datatype/ReferenceDatatypeEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/reference-datatype/ReferenceDatatypeEditor.vue
Show resolved
Hide resolved
3f68847
to
fa5dc08
Compare
10b4718
to
7e3d631
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
There was a problem hiding this 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 😅
There was a problem hiding this 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
There was a problem hiding this 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/src/arches_lingo/components/generic/reference-datatype/ReferenceDatatypeEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/LabelEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/LabelEditor.vue
Outdated
Show resolved
Hide resolved
arches_lingo/src/arches_lingo/components/generic/LabelEditor.vue
Outdated
Show resolved
Hide resolved
b03e64d
to
c290ff6
Compare
This reverts commit d325db5.
arches_lingo/serializers.py
Outdated
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) |
There was a problem hiding this comment.
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. 👀
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
arches_lingo/serializers.py
Outdated
label_language = label.appellative_status_ascribed_name_language[0] | ||
label_type = label.appellative_status_ascribed_relation[0] |
There was a problem hiding this comment.
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]
👍
There was a problem hiding this comment.
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.
arches_lingo/serializers.py
Outdated
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") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?)
arches_lingo/serializers.py
Outdated
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) |
There was a problem hiding this comment.
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.
arches_lingo/serializers.py
Outdated
and label_language["uri"] == new_label_language["uri"] | ||
): | ||
raise ValidationError( | ||
"A preferred label with the same language already exists for this scheme." |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
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 👍
Fixed in 35a1237 |
Resolves #147
Requires Arches References #58