Added deliteful/ScrollableContainer #20
Conversation
|
Among other changes, this PR addresses Bill's comments: inheritance from Widget now unnecessary, and reuse of the shared test cases from delite. |
|
Seems this PR is now ready to be merged. If no one objects, Adrian, can you merge it ? |
|
I'm confused about the tests. You have 3 files in tests/functional yet they are all HTML files; there's no functional automated test? (Having said that, I'm not sure it's practical to test scrolling via webdriver.) |
|
Yes, they are manual tests, complementing the automatic unit tests. I could have added some minimalist automatic testing but as you said it's not quite practical to test scrolling via webdriver. Two main reasons: the interaction is browser-dependant (mouse interaction with the scrollbar on non-touch devices, scroll gesture on touch devices), and checking the quality/performance of the scrolling is hard to automate. Since the scrolling is now done by the browser itself, and we don't want to test the browser feature but our stuff around it, I would think the automatic unit testing would be good enough for now, but of course we might improve it later. |
|
It just seems strange to put manual tests in test/functional. Was that what we agreed on? I thought they were supposed to go in samples/ but I can't remember for sure. |
|
The agreement was to have no manual tests ;) Only intern functional and unit. And samples of usage must indeed be in samples. |
|
Well, from "delite(ful)/tests/functional/MyClass.html (even if that is used standalone this is still some kind of functional tests not a unit test for sure)" in ibm-js/sdk#2 I understood that this is "tolerated". |
|
I said "used standalone" which does not state it is its sole purpose, my idea was that it can be used standalone but my feeling is that there is always something to test automatically on top of that? Also I think there is a value making sure an interaction is always automatically performed on a widget. This makes sure at least we are not breaking on interaction (for example). That said I guess this can wait post merge. |
|
Okay, so if nobody objects I would improve that post merge, as Christophe said. |
|
Committed in master: 36ad53b |
This means that buildRendering() runs before any user the user defined parameters
are available.
This change is necessary to be forward compatible with browsers that implement
document.register() natively, because in that case programmatic creation (w/out
the syntactic sugar) will be:
var node = document.createElement("dui-slider");
node.max = 10;
Other changes:
- Removed runAfterRender() helper.
- Added preCreate() lifecycle method that executes before buildRendering().
- Fixed a few widgets that were depending on constructor() getting called;
constructor() doesn't get called anymore with custom elements.
- Removed widgetId attribute setting on nodes.
Open issues:
- _Invalidating is presumably emitting unwanted events for changes that are due to
initialization parameters; it should only send events for changes after this._started.
- Specifying event handlers declaratively (ex: <dui-button onfoo=...> for custom events
likely isn't working.
Fixes #20.
This means that buildRendering() runs before any user the user defined parameters
are available.
This change is necessary to be forward compatible with browsers that implement
document.register() natively, because in that case programmatic creation (w/out
the syntactic sugar) will be:
var node = document.createElement("dui-slider");
node.max = 10;
Other changes:
- Removed runAfterRender() helper.
- Added preCreate() lifecycle method that executes before buildRendering().
- Fixed a few widgets that were depending on constructor() getting called;
constructor() doesn't get called anymore with custom elements.
- Removed widgetId attribute setting on nodes.
Open issues:
- _Invalidating is presumably emitting unwanted events for changes that are due to
initialization parameters; it should only send events for changes after this._started.
- Specifying event handlers declaratively (ex: <dui-button onfoo=...> for custom events
likely isn't working.
Fixes #20.
This means that buildRendering() runs before any user the user defined parameters
are available.
This change is necessary to be forward compatible with browsers that implement
document.register() natively, because in that case programmatic creation (w/out
the syntactic sugar) will be:
var node = document.createElement("dui-slider");
node.max = 10;
Other changes:
- Removed runAfterRender() helper.
- Added preCreate() lifecycle method that executes before buildRendering().
- Fixed a few widgets that were depending on constructor() getting called;
constructor() doesn't get called anymore with custom elements.
- Removed widgetId attribute setting on nodes.
Open issues:
- _Invalidating is presumably emitting unwanted events for changes that are due to
initialization parameters; it should only send events for changes after this._started.
- Specifying event handlers declaratively (ex: <dui-button onfoo=...> for custom events
likely isn't working.
Fixes ibm-js#20.
Contains:
Notes: