I need to use the features of the submission checklist code (e.g. add elements, …) in my own code / customized parts of OJS.
To avoid recreating the wheel I want to refactor the existing code in such a way that it is reusable hence the name custom checklist. It would require almost similar operations as described in issue Refactor review forms feature to reusable custom forms feature. Also to avoid the need to merge constantly between possible submission checklist changes and my own custom checklist code i would like to provide a pull request to get the chances into the official repo. Is there a chance that the PR would be accepted?
Am I right in thinking that you want to have a custom form that authors must fill out when submitting? So instead of just a checklist, they may also have input fields, select fields and other kinds of input?
If so, you’ll probably run into the same caveats that I described in this comment on the issue you linked. In short, I’m in favor of the idea but because we are doing some major refactoring of our form handling, now is a difficult time to merge in code, because much of what you will build off may change in the next year.
I’d encourage you to file an issue in our GitHub repo that provides more details about what you want to be able to change in the submission forms. That will help us design something that is more flexible when we get to it. And we can discuss ways in which you might build off of the new form system once it is released with 3.2. Depending on your timeline it might be possible to do your work on top of that.
no, i just want to reuse the checklist functionallity, to be specific, we have the requirement of “submission checklist per section”. So i need to be able to configure a submission checklist per section, not per journal as it is implemented currently. Simply speaking, what i would do is to
provide an extension point to specify the context (currently its simply the journal retrieved from the request)
using that extension point in submission step 1, grid handler and form
defaulting the context to the journal as it is implemented right now
Ok, i forgot about the currently ongoing form refactoring, hmm i guess i will fiddle something together and create a issue / PR afterwards to show you the changes as describing it with just words is a bit difficult.
Ah, I see. So the trickiest part will actually be in creating the UI to create new checklists for each section. You can see an example of how we extend the forms to add/edit a section to add new fields in the BrowseBySection plugin:
Once you have those, you’ll need to pull the checklists out during the submission process, and write a little JavaScript that displays the correct one depending on which section has been selected.
Thanks @NateWr. I’m aware of this technique, i use it a lot already. The plugin adds 4 simple fields only but I need a grid, handler, form, dao and so on. I could simply copy and paste existing / similar OJS code and then make a checklist out of it but I’m not a fan of copy and paste, the DRY principle haunts me .
That’s why at first it was the review forms stuff that i refactored into custom forms (Refactor review forms feature to reusable custom forms feature · Issue #3971 · pkp/pkp-lib · GitHub) to avoid copy and pasting the whole review forms code. It works out pretty nicely so far. Then I refactored the submission checklist to custom checklist code (which is addressed in this thread) … and now I’m at a point where i also need lists with complex data that should be stored in _settings tables which again, at the core is the same as the checklist functionality. This means that i will refactor the custom checklists to custom lists to avoid violating the DRY principle again.
As you see it would be nice to have some base classes shipped with OJS / pkp-lib to inherit from when creating lists.
You don’t need to answer this post, I just wanted to write down my thoughts to avoid losing the ideas / for later reference.
Sounds like you’ve got a good handle on things, @j1shin. At the moment, the base form component for creating lists is called ListBuilderHandler. You will find a number of files related to that, and classes which extend it under FilesListBuilderHandler, MultipleListsListBuilderHandler and other similar names.
These are being deprecated at the moment, and some of them are going away in 3.2. But the base ListBuilderHandler will probably still be there for at least one more major version.
.