-
Notifications
You must be signed in to change notification settings - Fork 13
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
Revert select value type support #277
Changes from 1 commit
b38cb2c
05abe44
aa0dbec
3abb3b0
b4a0d2b
c2be258
7d84ad3
e6d01b0
0a6010e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,7 +3,7 @@ import type { | |
KnownAttributeLocalNamedElement, | ||
LocalNamedElement, | ||
} from '@getodk/common/types/dom.ts'; | ||
import type { SelectElement } from '../../parse/body/control/select/SelectDefinition'; | ||
import type { SelectElement } from '../../parse/body/control/SelectControlDefinition.ts'; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Question: Why do we have one for Select, while not for Range, Note, Inputs? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I understand this question? If you're asking why we have a If you're asking about the |
||
|
||
const hintLookup = new ScopedElementLookup(':scope > hint', 'hint'); | ||
const itemLookup = new ScopedElementLookup(':scope > item', 'item'); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,8 +6,8 @@ import { ControlDefinition } from './control/ControlDefinition.ts'; | |
import { InputControlDefinition } from './control/InputControlDefinition.ts'; | ||
import { RangeControlDefinition } from './control/RangeControlDefinition.ts'; | ||
import { RankControlDefinition } from './control/RankControlDefinition.ts'; | ||
import type { AnySelectDefinition } from './control/select/SelectDefinition.ts'; | ||
import { SelectDefinition } from './control/select/SelectDefinition.ts'; | ||
import type { AnySelectControlDefinition } from './control/SelectControlDefinition.ts'; | ||
import { SelectControlDefinition } from './control/SelectControlDefinition.ts'; | ||
import { TriggerControlDefinition } from './control/TriggerControlDefinition.ts'; | ||
import { UploadControlDefinition } from './control/UploadControlDefinition.ts'; | ||
import { LogicalGroupDefinition } from './group/LogicalGroupDefinition.ts'; | ||
|
@@ -24,7 +24,7 @@ export interface BodyElementParentContext { | |
|
||
// prettier-ignore | ||
export type ControlElementDefinition = | ||
| AnySelectDefinition | ||
| AnySelectControlDefinition | ||
| InputControlDefinition | ||
| RangeControlDefinition | ||
| RankControlDefinition | ||
|
@@ -48,7 +48,7 @@ const BodyElementDefinitionConstructors = [ | |
PresentationGroupDefinition, | ||
StructuralGroupDefinition, | ||
InputControlDefinition, | ||
SelectDefinition, | ||
SelectControlDefinition, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe this will expand to something like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can see that becoming an abstract base class for select/select1/rank. Both concrete classes would still be enumerated here though, as it's used for instantiation during parsing. And the base class would make even more sense when we split select/select1. |
||
RangeControlDefinition, | ||
RankControlDefinition, | ||
TriggerControlDefinition, | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,8 +1,9 @@ | ||
import { getValueElement, type ItemElement } from '../../../../lib/dom/query.ts'; | ||
import { ItemLabelDefinition } from '../../../text/ItemLabelDefinition.ts'; | ||
import type { XFormDefinition } from '../../../XFormDefinition.ts'; | ||
import { BodyElementDefinition } from '../../BodyElementDefinition.ts'; | ||
import type { AnySelectDefinition } from './SelectDefinition.ts'; | ||
import type { ItemElement } from '../../../lib/dom/query.ts'; | ||
import { getValueElement } from '../../../lib/dom/query.ts'; | ||
import { ItemLabelDefinition } from '../../text/ItemLabelDefinition.ts'; | ||
import type { XFormDefinition } from '../../XFormDefinition.ts'; | ||
import { BodyElementDefinition } from '../BodyElementDefinition.ts'; | ||
import type { AnySelectControlDefinition } from './SelectControlDefinition.ts'; | ||
|
||
export class ItemDefinition extends BodyElementDefinition<'item'> { | ||
override readonly category = 'support'; | ||
|
@@ -13,7 +14,7 @@ export class ItemDefinition extends BodyElementDefinition<'item'> { | |
|
||
constructor( | ||
form: XFormDefinition, | ||
override readonly parent: AnySelectDefinition, | ||
override readonly parent: AnySelectControlDefinition, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Question: I'm supposing that rank will use this, too. Does it make sense?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Another good catch! Yeah, this module is moving up out of the For what it's worth, I'm not sure the |
||
element: ItemElement | ||
) { | ||
const valueElement = getValueElement(element); | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Question: Does body parsing happen after the engine's client? I mean, the entry point is client then body parsing runs There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hopefully you've had a chance to read the WIP architecture docs I pushed up EOW, which I think addresses this much better than I can here. Briefly, the current parsing order is roughly:
A client calls the engine's |
This file was deleted.
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.
Suggestion:
I'm not suggesting this as a significant change, but rather as an improvement to help new contributors and streamline the process. Grouping by entity, like this, could make it easier for newcomers to learn, discover, and quickly add new components.
/xforms-engine
|---/src
|---index.ts
|---hierarchy.ts
|---|---/errors
|---|---|---< common-thing >Error.ts
|---|---/controls
|---|---|---/select
|---|---|---|---SelectNode.ts
|---|---|---|---SelectState.ts
|---|---|---|---SelectControl.ts
|---|---|---|---SelectCodec.ts
|---|---|---|---Select< thing >.ts
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 really like this idea, and I've filed #282 to track it. In reality, I think we'll find it's actually a pretty big task, in terms of modeling, naming, and careful consideration of how we apply the concept to internals. I'm not sure whether it could work given the domain concepts and how we model them. But it's a technique for code organization I really like where I've seen it applied (and one we definitely should discuss for the UI package!).
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.
Awesome! Thank you!