Skip to content
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

Fix part of #122: Add a proto for explorations #128

Merged
merged 10 commits into from
Sep 21, 2019
Merged

Conversation

vinitamurthi
Copy link
Contributor

Explanation

This PR creates a proto for handling an exploration instance. It will be used by the exploration controllers and views
Fixes part of #115

Checklist

  • The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
  • The PR explanation includes the words "Fixes #bugnum: ..." (or "Fixes part of #bugnum" if the PR only partially fixes an issue).
  • The PR follows the style guide.
  • The PR does not contain any unnecessary auto-generated code from Android Studio.
  • The PR is made from a branch that's not called "develop".
  • The PR is assigned to an appropriate reviewer.

Copy link
Member

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Overall LGTM, but I'd like to do one more pass after these comments are addressed.

model/src/main/proto/exploration.proto Outdated Show resolved Hide resolved
model/src/main/proto/exploration.proto Outdated Show resolved Hide resolved
model/src/main/proto/exploration.proto Outdated Show resolved Hide resolved
model/src/main/proto/exploration.proto Show resolved Hide resolved
model/src/main/proto/exploration.proto Outdated Show resolved Hide resolved
model/src/main/proto/exploration.proto Show resolved Hide resolved
model/src/main/proto/exploration.proto Outdated Show resolved Hide resolved
model/src/main/proto/exploration.proto Outdated Show resolved Hide resolved

// Data for a single rule spec
message RuleSpec {
map<string, HtmlStringList> inputs = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is HtmlStringList the only type for inputs, or can it be something else? It appears this was represented with 'Any' in the original structure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the file the comment - https://github.com/oppia/oppia/blob/ec254cfcc87843c36e24d68d335cc811536fb2d4/core/domain/state_domain.py#L1146 points to, I believe they are a list of html strings

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per https://github.com/oppia/oppia/blob/develop/extensions/interactions/rule_templates.json I think the inputs are typed based on the rule spec. E.g. some can be CodeString, others Fraction, or list of HTML strings. I think for the interactions we're supporting (#28, #29, #30, #31, #32, #33, #34, #35) we should support the corresponding rulespecs for them. Should we be using 'anyof' here, instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added them as part of the InteractionObject message. Added the new types of input based on interactions mentioned in #28 -> #35

// Maps from: data/src/main/java/org/oppia/data/backends/gae/model/GaeCustomizationArgs.kt
message CustomizationArgs {
bool parse_with_jinja = 1;
string value = 2;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is value always type string? This was 'Any' in the GAE model.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on a search of the codebase - https://github.com/oppia/oppia/search?l=YAML&p=2&q=customization_args
I could see that each of the customization args have a value field that is a string. Not sure if we need anything else apart from the value field?
@seanlip is there a way to find out all the possible customization args we can get?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @vinitamurthi -- "customization args" is an overloaded term. They exist for interactions, parameters, and a whole bunch of other things.

For interactions: see extensions/interaction/NameOfInteraction and look at the python file. There's a list of customization arg descriptions in there, with their possible schemas.

For parameters, it's defined here: https://github.com/oppia/oppia/blob/develop/core/domain/param_domain.py#L99

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Separated customization args for param changes and interactions.
For interactions I noticed this comment: https://github.com/oppia/oppia/blob/1b668fd3c74f9481232a3c1c73ecd632036a902e/core/domain/state_domain.py#L340 where its a map from name to a default value.
Default value can be different types so I looked at the different possible values in extensions/interaction/NameOfInteraction and added them to an InteractionObject message

@BenHenning BenHenning changed the title Fix part of #115: Add a proto for explorations Fix part of #122: Add a proto for explorations Sep 20, 2019
@BenHenning
Copy link
Member

Hi @vinitamurthi is this ready for another review? If so, please reassign to me so that I know. Thanks!

@vinitamurthi
Copy link
Contributor Author

This is now ready for a second pass..PTAL @BenHenning !

Hint hint = 5;
Outcome default_outcome = 6;
// Mapping from the name of a customization arg to the default interaction
// object of the customization arg
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: remove extra space between 'object' and 'of'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


// Data for a single rule spec
message RuleSpec {
map<string, HtmlStringList> inputs = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per https://github.com/oppia/oppia/blob/develop/extensions/interactions/rule_templates.json I think the inputs are typed based on the rule spec. E.g. some can be CodeString, others Fraction, or list of HTML strings. I think for the interactions we're supporting (#28, #29, #30, #31, #32, #33, #34, #35) we should support the corresponding rulespecs for them. Should we be using 'anyof' here, instead?

}

// Structure representing a graph object.
message Graph {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above--let's only focus on the prototype interactions for now: #28->#35.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

option java_multiple_files = true;

message InteractionObject {
oneof object {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe: oneof object_type. Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added an object type, so changed this field to value - what do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wasn't quite what I meant--followed up below. Let me know if you want to discuss further.

@vinitamurthi
Copy link
Contributor Author

@BenHenning made the changes you requested, PTAL!

Copy link
Member

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @vinitamurthi--after my last set of comments are addressed this looks good to me. You can re-assign to me if you want me to take one more pass, but otherwise if you address my comments feel free to submit this.

// Structure for any interaction object
message InteractionObject {
ObjectType object_type = 1;
oneof value {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I was wondering if we could call the oneof object_type. Do we need a separate enum? I thought oneof generated an enum for us to switch on & retrieve the value. If that's right, we don't need the extra enum and it's a bit redundant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah oops I misunderstood. Changed it

}
}

// Structure containing lists. Note we should fill only
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe instead we can just make this a StringList. At that point, the extra caveat in the documentation doesn't seem necessary since it's probably sufficiently clear that the purpose of the proto is to be a StringList.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

ObjectType number_type = 1;
float real = 2;
Fraction fraction = 3;
// Controllers are expected to convert the unit into a string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually a domain object, not a view model object, so we could conceivably have different model objects that contain UI-specific data. We should model these protos based on what we need to store on-disk. If units are already stored as strings in Oppia, then let's keep this. Otherwise, let's use a type closer to what the backend uses.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good..based on the schema here - https://github.com/oppia/oppia/blob/ae11e9dbeac66b5faeb68b7a2b1f16ccfdbc5ba6/extensions/objects/models/objects.py#L937
I believe there is a string value and an int value

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I confirm there is indeed a string value and an int value, but note that a "Units" object is a list of (string, int) things.

For example, "kg m s^-2" is represented as [(kg, 1), (m, 1), (s, -2)] (but with dicts instead of tuples.


// Structure for a number with units object.
message NumberWithUnits {
ObjectType number_type = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this maybe instead be a oneof between the float & Fraction? I don't think we'd ever have a NumberWithUnits containing a list of strings, for instance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@vinitamurthi
Copy link
Contributor Author

@BenHenning I made the changes and I am merging this now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants