-
-
Notifications
You must be signed in to change notification settings - Fork 7
Add a stand-alone metadata editing profile and streamline code #201
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
base: main
Are you sure you want to change the base?
Conversation
69fa292 to
de104ec
Compare
duncdrum
left a comment
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 this also needs a rebase. The repo.xml should not have been updated, adding some tests to the metadata profile would be great.
de104ec to
ce84999
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.
Some issues I found testing this PR:
- when I open a document in JinnTap (say the Leibniz), I get an error in the console when I click on the header editing icon

- the sample standalone header editing form is very basic. It would be great to at least have a repeat for the author, so users get an idea how this would look like in code.
- the styling of the save button in the standalone header editing form looks weird:

- the forms and metadata-editor profile should have a README with some documentation to help users get started on customizing the forms for their own needs.
But if you could just look into the first issue, I would go ahead and merge this PR to make it easier for us to continue.
So it can be opened separately from jinntap. Useful for larger metadata panels
fixed/updated bindings now always using 'authority-default' as instance;
it's standalone by default now
The result of saving is some json. Not the XML instance
It requires some assumptions that do not always hold
|
Fixed that silly error. Disabled create-nodes for it. While create-nodes would be really nice for this feature, there are some issues with it. Because the instance is loaded later in the jinntap integration, the form is not ready yet. However, the create nodes stuff kicks in, which does not where to place nodes in the fully empty instance, thus crashing out. Maybe later. It's not needed anyway. Furthermore, the styling is fixed, and the authors are in a repeat now. |
|
Added a readme on the metadata panel on how to customize from it |
1 similar comment
|
Added a readme on the metadata panel on how to customize from it |
Makes it a lot easier to maintain. No need to fork the whole' file for only toolbar changes
No description provided.