Core: Split up into individual modules #1569
Conversation
|
How about putting these into their own folder? Or moving widgets into a folder? Something something with less clutter? |
|
In mobile we have a widgets folder |
|
Though moving the core stuff into its own folder is a lot easier since it wont require changes to every test file :-) |
|
I'd be fine with a |
|
This now moves the widgets into their own folder and the effects into their own. |
|
Folder changes look good. This still deletes There's missing deprecation comments for |
|
@jzaefferer ill add the comments and file but this actually is missing updating all the demos adding that right now. |
|
Why do some of the new files have copyright and AMD-property headers (like "//>>label"), others don't, e.g. |
|
I followed what the convention seemed to be already if its a file that is a "public" method that will show in DB it gets a header if its a private micro module it does not. |
|
There's no file that specifies |
|
@jzaefferer thats correct nothing should depend on. IT will be in the core. After it will have to be hard coded into the build. How is this handled today if you only select components that do not depend on core? |
|
I guess its just missing. I'd be fine with moving it back to |
|
Reviewed the rest of the commits, didn't notice any other issues. Will do some actual testing when demos are updated. |
|
@scottgonzalez what are your thoughts since you said to make this its own module? |
|
@jzaefferer demos are updated |
|
I don't actually have a good answer for this. I'd say that we should just make version a dependency on everything, but I'm not sure if that'd be annoying for users doing custom builds. |
|
Can we make this file (more) useful by having everything depend on it, and drop the |
|
Sounds ok to me. |
|
Widgets already have @Version defined and define their namespace if it does not exist. This is also not a "dependency" things function just fine with out it. I think it would make since for all the "core" files to depend on it maybe but not widgets. |
|
It's not a dependency in terms of needed functionality, but we always expect the version to be there. I'd prefer to have the widgets declare it as a dependency as well. |
|
@scottgonzalez it seems like we should remove it from the prototype of individual widgets then as it just seems redundant. |
|
It's not redundant. The version is in the prototype so that you can check the version on an instance. This is useful since you can load multiple versions simultaneously. |
|
@jzaefferer this is good to go again full passing tests on all commits |
| }; | ||
|
|
||
| } ) ); | ||
| ( function() { |
There was a problem hiding this comment.
Should mark this file as deprecated.
This more closely emulates what you get from the builder in terms of file order it also will error on any dependency issues.
|
@jzaefferer updated |
|
What do we need the remaining concat grunt task for? The output isn't used anywhere. Whoever built the 1.10 npm package still hasn't updated it to 1.11, so there's no point in worrying about that - though we should be publishing jQuery UI on npm... |
| @@ -14,334 +14,24 @@ | |||
| //>>docs: http://api.jqueryui.com/category/ui-core/ | |||
| //>>demos: http://jqueryui.com/ | |||
|
@jzaefferer anything else on this? |
|
Demos link in ui/core.js and grunt concat task, see comments above. |
|
Remove the now unused dependency, then this is good to land. |
|
Doing it now |
|
Closed in eeb9620 |
This breaks the core file up into small individual modules and updates all their dependencies