-
Notifications
You must be signed in to change notification settings - Fork 175
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
New Data Dictionary framework and module #6936
Conversation
@HenriRabalais can you have a look at this to see if it's possible to describe the biobank's data? The place to start would probably be the |
This adds the classes representing the data scope, data type, data cardinality, DictionaryItem (and dictionary Category) from PR aces#6936 but does not use yet use them.
This implements the known types of types from PR aces#6936.
* @license http://www.gnu.org/licenses/gpl-3.0.txt GPLv3 | ||
*/ | ||
|
||
class Fields extends \NDB_Page |
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.
no need for NDB_Page. implements RequestHandlerInetrface
would be enough.
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 don't see what the benefit of that would be.
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.
Better cohesion and reduced coupling. If you only need the handle function, and maybe _hasAccess, implementing RequestHandlerInterface is enough. I don't see what $identifer and $commentid means for a datadictionnary field. $fieldoptions, $dateoption adds confusion. What is the use of AddFile, AddSelect, ...? Will it use its LorisForm?
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.
To be honest I'd like to remove $identifier
and $commentid
from the page class in general, but when I tried doing that in #7414 the scope of the change exploded so I held back to do it later.
I don't think having methods that are uncalled adds any overhead and the properties in the page class add minimal. I just had a look through the code and hasAccess does seem to be the main benefit. Other than that, I think there's benefit in having a root to the class hierarchy, but I can change this to manually call hasAccess if you want.
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 made #7431 to work through what would be ideal in general outside of this PR.
@driusan can you point me to where i should be looking? this is a big PR and i don't know what it is exactly you want me to look at to see if something is missing. and what kind of 'types' are you referring to? thanks |
The |
This implements the known types of types from PR aces#6936.
Multiselects should have multiple cardinality. (See comment on #6939) |
This adds the classes representing the data scope, data type, data cardinality, DictionaryItem (and dictionary Category) from PR aces#6936 but does not use yet use them.
5258189
to
c6ffaeb
Compare
This adds the classes representing the data scope, data type, data cardinality, DictionaryItem (and dictionary Category) from PR #6936 but does not use yet use them. It gives us the ability to describe data dictionaries in LORIS.
656a936
to
5710a5f
Compare
…dule This extracts the portion of aces#6936 which relates to candidate variables in the `candidate_parameters` dictionary and puts it into a new PR for reviewability now that the classes which it depends on have been separately merged. TODO: [ ] Address comment about PSCID in aces#6936. [ ] Project should be an enumeration based on project table [ ] Subproject should be an enumeration based on subproject table
…dule This extracts the portion of aces#6936 which relates to candidate variables in the `candidate_parameters` dictionary and puts it into a new PR for reviewability now that the classes which it depends on have been separately merged. TODO: [ ] Address comment about PSCID in aces#6936. [ ] Project should be an enumeration based on project table [ ] Subproject should be an enumeration based on subproject table
…dule This extracts the portion of aces#6936 which relates to candidate variables in the `candidate_parameters` dictionary and puts it into a new PR for reviewability now that the classes which it depends on have been separately merged. TODO: [ ] Address comment about PSCID in aces#6936. [ ] Project should be an enumeration based on project table [ ] Subproject should be an enumeration based on subproject table
The value is being updated, not necessarily created.
0f161e2
to
312c1ed
Compare
@maltheism rebase done @xlecours my previous comment seems to be hidden since rebasing.. could you update or dismiss your review? I think I've responded to everything in it. |
@driusan I have added a comment there: #6936 (comment) |
This adds the classes representing the data scope, data type, data cardinality, DictionaryItem (and dictionary Category) from PR aces#6936 but does not use yet use them. It gives us the ability to describe data dictionaries in LORIS.
This updates the LORIS Data Framework to include a concept of a data dictionary that a module may manage. It adds a new "dictionary" module to manage the module dictionary but leaves the datadict module in place because it's currently the only place to manage the parameter_type table used by the DQT. The extension of the data framework to include dictionaries also includes many enhancements from the current "data dictionary" in LORIS which only includes a field name and description. Types, Scopes, and Cardinalities are added which more thoroughly describe the data and will eventually be able to be used to build richer data-type sensitive interfaces in places like the DQT. DictionaryItems implement the AccessibleResource interface to enable modules to give column-level granularity over data. Modules provide categories of DictionaryItems, which allows them to group items in the frontend. This is primarily to make it possible to filter the instruments from the "instruments" module (in the current data_dict module, the Source From options are literally populated by a call to \Utility::getAllInstruments()) in a manageable way, but can be used by any module that wants to group the fields. Instruments written in PHP must now implement a new getDataDictionary() abstract function to describe the fields provided by the instrument, but a LorisFormDictionaryImpl is provided which populates it in the same way that the lorisform_parser uses it to populate the parameter_type table.
This updates the LORIS Data Framework to include a concept of a data dictionary that a module may manage. It adds a new "dictionary" module to manage the module dictionary but leaves the
datadict
module in place because it's currently the only place to manage theparameter_type
table used by the DQT.The extension of the data framework to include dictionaries also includes many enhancements from the current "data dictionary" in LORIS which only includes a field name and description. Types, Scopes, and Cardinalities are added which more thoroughly describe the data and will eventually be able to be used to build richer data-type sensitive interfaces in places like the DQT. DictionaryItems implement the AccessibleResource interface to enable modules to give column-level granularity over data.
Modules provide categories of DictionaryItems, which allows them to group items in the frontend. This is primarily to make it possible to filter the instruments from the "instruments" module (in the current
data_dict
module, theSource From
options are literally populated by a call to\Utility::getAllInstruments()
) in a manageable way, but can be used by any module that wants to group the fields.Instruments written in PHP must now implement a new
getDataDictionary()
abstract function to describe the fields provided by the instrument, but aLorisFormDictionaryImpl
is provided which populates it in the same way that thelorisform_parser
uses it to populate theparameter_type
table. Thecandidate_parameters
andimaging_browser
also implement dictionaries in this PR.NB: I intend to try to break this PR into smaller, easier to review chunks, but it may be helpful to reviewers to have a PR with the entire dictionary overhaul for context.