However, I am having a hard time in passing the submissionId in the gridhandler.
Everything is ok when I open the metadata view in a submission. All the funders for that submission are listed. I can also add new funders or edit the old funders without a problem. However, when I save the funder form and the gridhandler is loaded again, I can not figure out how to pass the submissionId here: https://github.com/ajnyga/fundRef/blob/develop/controllers/grid/FunderGridHandler.inc.php#L52
During the first load I have the submissionId available through $request->getUserVar('submissionId'), but not after trying add/edit.
I was looking how you do this with the authors grid in the same modal, but function used there does not work when there is a plugin in the middle.
However, is there really no option of retreiving the submissionId for the gridhandler in a different way than passing it as a parameter between the gridhandler and the form attached to the grid? I think the current model would allow injecting a submissionId.
Basically all metadata plugins using a grid would benefit from a solution. The gridmodel is very handy way of adding complex metadata.
The authorization policy framework is what we rely on to turn element IDs into PHP-land objects – it allows us to specify in one place a set of rules permitting/denying access, so it’s not necessary to check every time an ID needs to be looked up. (For example, you’d need to ensure that the supplied submissionId belongs to the right journal, and the user is an editor of that journal, etc.)
This is why you’ll see calls e.g. to $this->getAuthorizedContextObject(ASSOC_TYPE_SUBMISSION) in the handler classes.
In order for this to work, you’ll need the handler to specify an authorization policy – in the cases of grids, sometimes it’s delegated to the data provider class. And you’ll need to ensure that the request passes the expected request parameters (e.g. submissionId) into the subrequest, which will sometimes mean adding it to the list of parameters that the Javascript toolset supplies for AJAX subrequests.
Let me know if there’s a particular aspect of this you’re getting stuck on and perhaps I can pick out an example from the codebase.
Regards,
Alec Smecher
Public Knowledge Project Team
Yes, I noticed that function in the authorGridHandler, but could not get it to work. I thought that the problem was that I was calling the grid through a plugin, but probably I was just missing an authorization policy, maybe. I will look at the authorgrid again.
Thanks for the pointers. I managed to solve the problem with the submissionId. The CrossRef funding registry plugin is basically ready now: https://github.com/ajnyga/fundRef
What I can not do via this plugin is to add the saved funding data to CrossRef exports. That would be a fairly straight forward thing to add to the CrossRef plugin, but I do not think that there is a hook available to do this through another plugin. What I can do (I think) is to add the funding data to OAI-PMH, but have not done that yet.
Hmm, I suspect you’d permit plugin-based augmentation of filters (e.g. the CrossRef filters, which transform objects to XML) pretty easily and generally with a few new hooks in lib/pkp/classes/filter/Filter.inc.php. Then the CrossRef filter (and any other) could go about its business not needing to consider potential augmentation, and your plugin could hook into the Filter.inc.php hooks to add whatever it wants before the results are returned.
Regards,
Alec Smecher
Public Knowledge Project Team
@asmecher, I think those hooks in the Filter class will not be so easy, at least not in this case: the hooks would be needed in special functions of the Crossref filter, in order to position the new XML elements at the right place i.e. to construct a valid XML. A hook in the base Filter class would above all have to be in the process function and would mean that the additional XML elements should be added at the end, when the XML is created, and thus would mean anew processing (of XML and OJS data). This applies for the filter framework in general, I think.
Thus, could we maybe in this case either a) assume Crossref plugin knows about the Founders plugin, so that we add the elements from withing the Crossref plugin, or b) add a hook in the Crossref filter at the correct place? (This would also apply to the DataCite and OpenAIRE plugin).
Or would you still prefer to use the hooks in the base Filter class?
I was thinking that the filter framework that could provide a hook permitting registrants to alter the DOM before it is returned from the filter. That way the Founders plugin, for example, could work with the CrossRef DOM however it wanted before letting the CrossRef filter pass it back up the call chain.
Regards,
Alec Smecher
Public Knowledge Project Team
OK, I would then do it so. That means, first Crossref DOM will be generated (export plugin), then the Funders plugin would get that DOM and it would then go element by element, see somehow what OJS article that is, get the appropriate funders and insert the new elements…
