Skip to content

Conversation

@RichBCurious
Copy link
Contributor

Reworked the promo code stuff. Added support for Interest Areas and Interest Subjects

UI FOR ABOVE NEEDS TO BE ADDED.

Currently, the Interest area/subject stuff is bypassed. A promo code can be specified. If found, that promo info will be associated with default interest area stuff (with bookmarks and interest tags that are added to the user)

Structure is now like so:
InitialLoginConfiguration
promoCode
interestAreas
tutorialInfo

InterestArea
name (e.g., sleep)
interestSubjects

InterestSubject
name (e.g.. exercise)
interestTags
bookmarks

TutorialInfo
custom tutorial question/answer strings

So, an InitialLoginConfiguration can have multiple interest areas associated with it. An interest area can have multiple subjects associated with it. and a subject can have multiple interest tags and bookmarks associated with it.

Interest areas also have a "preSelect" boolean associated with them. So, the interestAreas member in InitialLoginConfiguration is not a collection of InterestArea objects, but rather a collection of InterestAreaBoolean objects, which, as the name suggests, is a collection of InterestArea and Boolean (preSelect) values. I tried using Tuple2<InterestArea,Boolean>, but I couldn't get that to work with Hibernate, so I created the InterestAreaBoolean class. We may be able to refactor this in the future.

By the same token, the interestSubjects member of InterestArea is a collection of InterestSubjectBoolean objects, which also includes a preSelect.

As the name suggests, the preSelect is intended for the UI to pre-select those values after the user logs in and the user is presented with the (yet-to-be-implemented) UI. So, the idea is, every new user will be assigned an InitialLoginConfiguration (ILC) on their first login. This will be the default, if either no or an unidentified promo code is specified, or the configuration associated with a valid promo code is specified. The UI code will then take the interest areas of the ILC and display them in the list, pre-selecting all of the interest areas that have their preSelect flag set. Then, either on a different screen or maybe in another listbox on the same screen, the subjects will be displayed, based on which areas are selected. And like the areas, some (or all) of those subjects will be selected based on the preSelect flag associated with each. When the user clicks an "okay" or "done" (or whatever) button, all the interestTags and bookmarks associated with the selected subjects will be added to the user.

A secondary function of the preSelect flag is to indicate which areas and ultimately, which subjects of those areas should be selected by default in the absence of a UI. In fact, the current HomeController.index() code is doing this now, by calling userRegistrationService.selectPromoCodeDefaults (that line should be removed when the above UI is implemented--I put a note in the file). So, what that method does is, it takes the promo code and uses it to determine which ILC to use (as described above). Armed with the ILC, it sets the "default" bookmarks and interest tags as determined by the preSelect values for the interest areas and subjects. Note, by the way, that subjects should have at least one bookmark OR at least one interest tag associated with them. After all, the whole point of these things is to pre-set interest tags and bookmarks on the user.

UserRegistrationService has several methods that begin with "select". These methods all, ultimately set bookmarks and interest tags on the user. The methods that contain the word "Defauts", set the tags and bookmarks based on whether the preSelect tags are set for the area and subject. (So, for the subject's bookmarks and tags to be used, both the subject and area has to have their associated "preSelect" flag set, otherwise, those subjects will be filtered out.) The "Defaults" methods are all associated ILCs or InterestArea(s).

All the "select" methods that contain "Subject" in their name deal directly with the subject, so they automatically set the bookmarks and interest tags of those specified subjects. So, I would expect the most useful "select" method for the UI would be "selectInterestSubjectsByStrings, which accepts a user and a list of strings. The strings will be used to lookup the subject objects and in turn fetch the bookmark and interest tag lists associated with those subjects. So, the UI would just take the names/text of all the subjects that the user selected in the UI and pass those to that method to set the user's bookmarks and interest tags.

I added many unit and integration tests that illustrate how the various objects work. Look at those for usage help.

test/unit/us/wearecurio/model/unit
InitialLoginConfigurationSpec.groovy
InterestSubjectSpec.groovy
TutorialInfoSpec.groovy
test/integration/us/wearecurio/services/integration
UserRegistrationServiceIntegrationSpec.groovy
test/integration/us/wearecurio/controllers/integration
HomeControllerIntegrationSpec.groovy

…g with tests. (only checking in becuase need to check in to deal with production error.
…changed homecontroller to use service; logincontroller passes on promo code to home controller which in turn calls service; updated the view to use the custom settings for the tutorial; added and moved around integration tests to reflect and test new design
… being populated even when not in use. (Why?)
…uding interest areas and interest subjects
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.

2 participants