-
Notifications
You must be signed in to change notification settings - Fork 12
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
Second review of gpii.express module... #2
Conversation
…last conversation with Antranig. Attempted to migrate to using distributeOptions instead of component inspection. This works fine for middleware components (which are not nested), but does not work for router components (which can be nested). Will have to keep the previous approach until I either get advice for the group or can talk with Antranig again.
Conflicts: src/js/json.js src/js/urlencoded.js
…dependency from test "reqView" class. Added configuration and tests to test middleware being inappropriately exposed from either a child or a sibling.
…ving middleware isolation, per feedback from Antranig on the mailing list.
…d other common test components.
…arams with GET calls, for example).
… This is required to support GET /path/:param style bindings.
…f all-tests.js to use the IoC test framework.
@@ -1 +1,2 @@ | |||
placeholder, please ignore. | |||
# gpii-express | |||
A fluid module to load express.js |
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.
This should be fleshed out a little by explaining the particular goals and strategy of the integration. For example - our desire to have containment structure of Infusion component trees to mirror the mounting structure of express routers and middleware, the ability to access Infusion's facilities for inspecting and advising compound structures by integrators who want to bundle and modify existing apps, etc. Should also contrast this with Kettle, and emphasise that, for now, this is a less ambitious and more concrete integration that doesn't give access to any fresh request-scoped material (IoC components) beyond those which express already supplies - that is, its native request and response objects.
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.
Sorry, that was boilerplate that I obviously missed updating. This has now been greatly expanded.
…ner definitions per pull request feedback.
…per pull request feedback.
component.options.router.use(component.options.path, childComponent.getMiddleware()); | ||
} | ||
else { | ||
fluid.fail(new Error({message: "A component must expose a router in order to work with child middleware components."})); |
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.
Simply fluid.fail("A component etc." .... is fine
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.
Done.
…hat actually needs it.
@amb26, we are nearly done, I think. I could use feedback on the testCaseHolder, I couldn't wire in the two common steps to each sequence without encountering errors. The non-working configuration is there, but commented out. |
Antranig's comments via Skype:
|
The testCaseHolder has now been updated to wire in the common setup test sequence steps automatically. |
Congratulations, ADTKINS on having reached this great milestone on such a long and tortuous road :) |
I have completed another round of updates since our last discussion, and am submitting my work for review.
The biggest change is that gpii.express is now responsible for wiring all middleware and components together.