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

Gpii 2452 Initial Suggestions and Review #1

Merged
merged 239 commits into from
Jun 28, 2019
Merged

Conversation

sgithens
Copy link
Member

@sgithens sgithens commented Aug 5, 2017

This is the first PR for this repo. I realize there is a lot of work and mess that needs cleanup, but a first round of suggestions, especially for fluid and framework related stuff is appreciated.

https://issues.gpii.net/browse/GPII-2452

Temporarily including a local set of testData to ease development.
Committing default _settings.scss from Foundation 6.3.0 before making
modifications.
- Removing markdown descriptions for now.
- Changing "Add Pref Set" to "Add Context"
- Removing context icons and earcons buttons since we don't have any
  yet.
- Changed left hand product list to be <li>'s instead of <h4>'s
Factored left hand product list into a component and added a search
filter to the top of it.
- Numerous changes based off of continuing prototyping, and the UI
  review of June.
- Removing half baked settings reference page
- Created utility routine for filtering an index
- Updated usage in components
- Added some unit tests for it
- Removing numerous console.log statements
- Putting in a temporary fix for the add context dialog until it's
  refactored in to a proper component.
- Changed to Yes/No based on UI Review
- Renaming editprefset.js to editprefset-viewport.
- Setting up modelrelay from the main editPrefs component to the child
  product tables to save their search/filter settings in the event that
  page is rerendered, or we need to save all the settings.
@sgithens
Copy link
Member Author

@cindyli @amb26 I believe I'll addressed most of the feedback, and that the repo is hopefully in fairly maintainable shape now. There are a few comments that suggested improved decoupling between some of the components, but I think they will require a bit more work, so I would like to make jira tickets for them and mark them post 1.0

I do need to make a release of this for the project timeline, so if you're comfortable with this, I would like to merge what is currently here into the proper GPII repo and tag it.

}
});

gpii.devpmt.dialogs.confirmRemoveProductDialog.acceptConfirmDialog = function (closeDialog, prefsSet, product, editProductEnabled) {
Copy link
Member

Choose a reason for hiding this comment

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

As in other cases this simple sequential listener should be dismantled into two successive namespaced listeners with priority

Copy link
Member Author

Choose a reason for hiding this comment

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

This is a little bit of an edge case, and I have comments about it in the grade it inherits from. For certain dialogs that require this ordering, because of the way the Foundation close works, closing the dialog will stop the rest of the listener chain.

fluid.defaults("gpii.devpmt.editPrefs", {
gradeNames: ["gpii.devpmt.viewComponent"],
mergePolicy: {
allSolutions: "noexpand",
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 plenty wierd - how do values get into these options, and why mustn't they be expanded?

Copy link
Member Author

Choose a reason for hiding this comment

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

They are added by the gpii-handlebars helper tag that creates the component on the page template. They are listed as "noexpand", because some of the entries and syntax in them are interpreted as IoC references, variables, or other things during the component installation which tries to mangle them into something else.

Granted, there are a few other things that need to be included on a round of a ResourceLoader-isation, but I'd like to jira that and make it part of the next round of work.

src/js/client/helpers.js Outdated Show resolved Hide resolved
@sgithens
Copy link
Member Author

@amb26 I've either resolved or added some dialog on the most recent comments. Any chance I can merge this in to the GPII/gpii-devpmt repo at this point?

@amb26
Copy link
Member

amb26 commented May 29, 2019

Tests are currently hanging. I get a bunch of failed calls to "parse" as follows:

13:32:41.924:  Sending a POST request to: /ppt/dev/login on port 8085
13:32:41.928:  Ignoring call to invoker parse of component {
    "typeName": "kettle.dataSource.encoding.JSON5",
    "id": "1bp29b9s-762",
....
which has been destroyed

and then finally the sequence hang message

13:32:47.029:  Test case listener has not responded after 5000ms - at sequence pos 6 of 8 sequence element {
    "event": "{pptHomeRequest}.events.onComplete",
    "listener": "kettle.test.assertResponse",
    "args": {
        "message": "Checking for part of the html page",
        "string": "{arguments}.0",
        "request": "{pptHomeRequest}",
        "plainText": true,
        "expectedSubstring": "prefsSafe-alice"
    }
} of fixture Successfull login to PPT, and checking access to authorized page.

@sgithens
Copy link
Member Author

I saw this as well and have fixed them up, and also added the note in the README on the current dependence on having a GPII-2966 universal running.

Tests are currently hanging. I get a bunch of failed calls to "parse" as follows:

13:32:41.924:  Sending a POST request to: /ppt/dev/login on port 8085
13:32:41.928:  Ignoring call to invoker parse of component {
    "typeName": "kettle.dataSource.encoding.JSON5",
    "id": "1bp29b9s-762",
....
which has been destroyed

and then finally the sequence hang message

13:32:47.029:  Test case listener has not responded after 5000ms - at sequence pos 6 of 8 sequence element {
    "event": "{pptHomeRequest}.events.onComplete",
    "listener": "kettle.test.assertResponse",
    "args": {
        "message": "Checking for part of the html page",
        "string": "{arguments}.0",
        "request": "{pptHomeRequest}",
        "plainText": true,
        "expectedSubstring": "prefsSafe-alice"
    }
} of fixture Successfull login to PPT, and checking access to authorized page.

@sgithens
Copy link
Member Author

@amb26 Having fixed up the existing tests, I'd like to potentially merge and tag this on Monday if you're feeling comfortable with it for now.

@amb26
Copy link
Member

amb26 commented Jun 17, 2019

I tested this with an instance of the GPII-2966 universal running on the local machine, and got just the same failure as listed above. I did notice that the universal instance got a connection on the new /prefssafes endpoint as below, so at least something is going right:

12:38:30.826:  Invoking handler gpii.preferencesServer.prefsSafeList.handler for route /prefssafes with expectedGrade kettle.request.htt
12:38:30.844:  Kettle server allocated request object with type gpii.preferencesServer.prefsSafeList.handler
12:38:30.847:  DataSource Issuing HTTP request with options {
    "port": 25984,
    "method": "GET",
    "headers": {

    },
    "protocol": "http:",
    "auth": null,
    "host": "127.0.0.1",
    "hostname": "127.0.0.1",
    "path": "/gpii/_design/views/_view/listPrefsSafes",
    "termMap": {

    },
    "url": "http://localhost:25984/gpii/_design/views/_view/listPrefsSafes",
    "directModel": {

    },
    "operation": "get",
    "reverse": false,
    "writeMethod": "PUT",
    "notFoundIsEmpty": true
}

@sgithens
Copy link
Member Author

sgithens commented Jun 20, 2019

@amb26 Hi! I just cloned a fresh copy of both these branches and was able to run the tests successfully, as well as start it up and use the webapp in a browser.

It looks above like maybe there is something wrong with the couch instance?

In order to start up the GPII-2966 universal branch I did:

#host machine
vagrant up
# in the fedora linux terminal
cd sync/universal
./scripts/vagrantCloudBasedContainers.sh

I then changed the Virtual Box port forwarding to send 9081 -> 8081

@sgithens
Copy link
Member Author

@amb26 Ok, here are the exact steps I used to run this requiring zero docker or vagrant containers. (other than the fact that my local couchDB instance runs in a docker container, but any Couch available on 8081 should be fine). Obviously the remotes don't need to be renamed, but I wanted to paste the exact commands I used.

  1. CouchDB running on port 8081, with an empty datastore, or at least no gpii database, however you like to do that.

  2. Universal GPII-2452

git clone [email protected]:GPII/universal.git
cd universal/
git remote rename origin GPII
git checkout -b GPII-2966 GPII/GPII-2966
npm install
GPII_COUCHDB_URL="http://localhost:5984/gpii" GPII_APP_DIR=$(pwd) bash -c ./scripts/deleteAndLoadSnapsets.sh

export NODE_ENV=gpii.config.preferencesServer.standalone.production
npm start
  1. PPT
git clone [email protected]:sgithens/gpii-devpmt.git
cd gpii-devpmt/
git remote rename origin sgithens
git checkout -b GPII-2452 sgithens/GPII-2452
npm install
npm test

@amb26
Copy link
Member

amb26 commented Jun 28, 2019

Cheers - the test coverage of this pull is extremely bad (25% branch coverage) but I am merging since I have now been able to verify the tests

@amb26 amb26 merged commit 635fe7b into GPII:master Jun 28, 2019
@sgithens sgithens deleted the GPII-2452 branch November 1, 2019 20:23
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.

4 participants