-
Notifications
You must be signed in to change notification settings - Fork 332
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
TSK-1682: Introduced Schema module #5240
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Petr Vyazovetskiy <develop.pit@gmail.com>
Just curious: why do not use |
import { mergeIds } from '@hcengineering/platform' | ||
|
||
export { schemaId } from '@hcengineering/schema' | ||
export default mergeIds(schemaId, schema, {}) |
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.
So, schema
plugin is effectively empty. Should we drop it and convert schema-resources
into package, maybe? But keep in mind we still need model-schema
plugin to register mixin
import type { JSONSchema7 } from 'json-schema' | ||
|
||
/** @public */ | ||
export interface Schema extends Obj, JSONSchema7 {} |
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.
@aplatoff Let's move here, so we could resolve the thread later.
Just curious: why do not use
platform
's model for that? Is there any limitations and it can not cover some cases?
What exactly do you mean? The module does use platform
's native data structures like Obj
, Doc
and Mixin
. No limitations there, they do perfectly fit our needs 👍🏽
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 mean that since both the platform and JSON Schema are focused on modeling data structures, why do we need two different mechanisms for modeling?
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.
Any comments on this? :) @anotherpit
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.
Signed-off-by: Petr Vyazovetskiy <develop.pit@gmail.com>
Signed-off-by: Petr Vyazovetskiy <develop.pit@gmail.com>
Signed-off-by: Petr Vyazovetskiy <develop.pit@gmail.com>
Signed-off-by: Petr Vyazovetskiy <develop.pit@gmail.com>
For upcoming implementation of Recruit Script feature we need a way to:
Think of something like Google Forms or Typeform. And also think of JSON schema as a comprehensive and standard language to describe forms.
So here I introduce Schema module which provides a set of context-agnostic building blocks to let any other Huly module incorporate forms built by one users and filled by others. The first module to utilize Schema will be Recruit, but this will happen in the next PR.
Huly®: UBERF-6413