Add Scope, Cardinality, Type, and DictionaryItem classes #6938
Conversation
driusan
added
Blocking
| * A Many Cardinality signifies that each data point will | ||
| * have zero or more values associated. For instance, | ||
| * the T1 scans acquired at a session. |
There was a problem hiding this comment.
feels like the example is a bit too specific, why not use something like For instance, site affiliations for a user for us non-imaging people
There was a problem hiding this comment.
I don't mind changing the example but I think site/project affiliations is a bad example because there's no "user" scoped data, and the example might get confusing since site/project affiliations exist on both candidate and session scopes.
There was a problem hiding this comment.
how about using the candidate/session relationship then ? a candidate can have 0 to many sessions
There was a problem hiding this comment.
That would be confusing too though, because there's the session scope and there's no variable named "Session", and session based data is usually described as 1:1 with a session scope, not 1:many with the candidate.
| Type $t, | ||
| Cardinality $c |
There was a problem hiding this comment.
why single letter variables, i'm not a big fan and in the long run they always tend to be a hindrance (same goes for shortcuts like cand for candidate...)
There was a problem hiding this comment.
It's just the argument name in the constructor, the context only lasts long enough to assign it to a property right below.. the property name is the full word.
| protected $name; | ||
| protected $description; | ||
| protected $scope; | ||
| protected $typ; |
There was a problem hiding this comment.
type is a reserved keyword in php.
There was a problem hiding this comment.
at least I thought it was and editor was highlighting it as one.. I'll look into it a little more.
| * The Scope class is final because the list of enumeration types | ||
| * can not be dynamically extended without modifying all places | ||
| * that must deal with the enumeration options. |
There was a problem hiding this comment.
this seems limiting to projects wanting to define their own scopes... why not a database table defining the constants...
would avoid overriding/overloading specially since we dont offer any easy overriding structure for the src directory
There was a problem hiding this comment.
Scopes can't be extensible because everywhere in the code that deals with the data needs to understand how to deal with that scope. Let's say a module added a scope named "foobar" and someone accessed that a variable with that scope in the DQT. Questions like "how should this be displayed? How does it relate back to candidates? How does it relate to sessions? Does it need to show a list of sessions to select? How does it get displayed in the results table? How do I join it with candidate scoped data to show in a row?" need to be understood by the code to build the interface and display results.
There was a problem hiding this comment.
(if you have a suggestion for how to make the comment more clear I'll update it.)
There was a problem hiding this comment.
no your right... I'm just thinking if there is a way we can add project defined scopes in the same way. my immediate interest is the Biospecimen scope for CBIGR
There was a problem hiding this comment.
it could come later though
There was a problem hiding this comment.
There are similar problems with things like imaging QC. "Pass/Fail" is really file scoped data but there is no file scope. For now I've defined them as "many" cardinality scoped to the session.
| Type $t, | ||
| Cardinality $c |
There was a problem hiding this comment.
It's just the argument name in the constructor, the context only lasts long enough to assign it to a property right below.. the property name is the full word.
| * A Many Cardinality signifies that each data point will | ||
| * have zero or more values associated. For instance, | ||
| * the T1 scans acquired at a session. |
There was a problem hiding this comment.
That would be confusing too though, because there's the session scope and there's no variable named "Session", and session based data is usually described as 1:1 with a session scope, not 1:many with the candidate.
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.
driusan
force-pushed
the
NewDataDictionaryTypes
branch
from
20bf05b to
098c30a
Compare
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 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.