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

move requirejs base path out of js directory #8382

Closed
ewinslow opened this Issue May 29, 2015 · 0 comments

Comments

Projects
None yet
1 participant
@ewinslow
Member

ewinslow commented May 29, 2015

Seems to me the best way to do this is alias all js/foo.js views to foo.js (and js/foo to foo.js too. Unlikely that there will be both js/foo and js/foo.js in the same plugin).

Either that or we move all static assets into the js directory, but that seems distasteful to me since images, CSS, and templates are not js. And we have a lot of php views outside js/* which we'd like to place CSS and js resources next to. In particular, I'm thinking of the resources/* views which are about to land.

@ewinslow ewinslow added this to the Elgg 2.0.x milestone May 29, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

feature(assets): Get rid of js/ and css/ directories
All views are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

feature(assets): Get rid of js/ and css/ directories
All views are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

feature(assets): Get rid of js/ and css/ directories
All views are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

@ewinslow ewinslow referenced this issue Jun 19, 2015

Merged

Ditch js/* and css/* views prefixes #8526

6 of 6 tasks complete

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 23, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 23, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 24, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 24, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 24, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 24, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 25, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

@ewinslow ewinslow closed this in #8526 Jun 26, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment