I understand what you mean. For my gem oojspec and oojs I use the
manifest approach you have described:
https://github.com/rosenfeld/oojspec/blob/master/app/views/oojspec/runner.html.erb#L8
https://github.com/rosenfeld/oojspec/blob/master/lib/assets/javascripts/oojspec.js.coffee
https://github.com/rosenfeld/oojspec/blob/master/vendor/assets/javascripts/buster/all.js.coffee
You'll notice I have submodule to third-party libraries (Buster.js):
https://github.com/rosenfeld/oojspec/tree/master/external/busterjs
Then I symlink the ones I'm interested in here (yes, I know this won't
work on Windows, but I don't think I would get any contributions from
Windows users anyway):
https://github.com/rosenfeld/oojspec/tree/master/vendor/assets/javascripts/buster
The same happens with oojs. Submodules:
https://github.com/rosenfeld/oojs/tree/master/resources
Linked assets:
https://github.com/rosenfeld/oojs/tree/master/vendor/assets/javascripts
Then the custom assets go into the lib directory instead of the vendor one:
https://github.com/rosenfeld/oojs/blob/master/lib/assets/javascripts/oojspec_helpers.js.coffee
But I do share your feeling that it should be easier to use
third-library JavaScripts in Rails.
Maybe we could support something like AssetsDependencies similar to a
Gemfile where you would specify the url to the assets or their
repositories and what files should be required and in which order (or
specify their dependencies) so that we could run some rake task to
download them and write the manifest files. In that case we could add
those files to the VCS or just do that dynamically before deploying like
it happens with "rake assets:precompile".
I'd love to see something like that for Rails. Currently whenever I want
to use some library with Rails I have to write my own gem when I don't
find one, as it happened with this one:
https://github.com/rosenfeld/jquery-layout-rails
What do you think about the idea of Rails providing something like the
AssetsDependencies DSL and a rake task as mentioned above?
Best,
Rodrigo.
Em 04-08-2012 13:50, Andrew Vit escreveu:
In 2fe70c1 (last year), rails changed from a static list of assets.paths to
automatically register any path under assets/*. (This was not reflected in
Rails Guides so I pushed an update to docrails.)
However, in my opinion, these automatic asset paths create confusion.
The result is that the first-level directories under `(app|lib|vendor)/assets`
get swallowed and if I put assets into a directory of my own naming, it will
conflict with assets from another asset path. e.g.
app/assets/images/icons/close.png
vendor/assets/xyz/icons/close.png
Here, the path segments "images" and "xyz" become asset path roots, so both of
the above resolve as icons/close.png, and serve from /assets/icons/close.png. (If you didn't expect
that, I should point out that the file from app will take precedence.)
I don't know if I'm missing how this is expected to be used. I might expect
app/assets/stylesheets, lib/assets/stylesheets, and vendor/assets/stylesheets
to correspond and mask each other, but not a subdirectory of my own naming.
Take for example a typical frontend widget I might want to download and install:
foo/widget.js
foo/styles.css
foo/images/click.png
If I want to keep this in a namespaced asset bundle instead of reorganizing it into separate
javascripts/stylesheets/images directories, I can't just drop the folder into vendor/assets, as the asset paths will
swallow the "foo" directory name, leaving the files naked in public/assets. In my manifests, these also
automatically become available directly as "styles.css" and "widget.js" without a "foo/"
prefix.
I could arbitrarily put it into vendor/assets/javascripts/foo (or
vendor/assets/whatever/foo), but that makes no sense: it's not all just
javascripts, it's a whole package. Is it really the right solution to just nest
things 2 levels down so as not to lose the subdirectory for namespacing?
For vendor/assets packages, ideally I think the way to handle such packages is to define a
"foo.js" and "foo.css" manifest to wrap the vendored package, and keep all its
files scoped under its own directory, e.g.
vendor/assets/foo.css # manifest file: //= require
'./foo/widget.css'
vendor/assets/foo.js # manifest file: //= require
'./foo/widget.js'
vendor/assets/foo/widget.js
vendor/assets/foo/styles.css
vendor/assets/foo/images/click.png
(Alternately, the manifests could be index files inside the folder.)
These would correspond to the public paths:
/assets/foo/styles.css # not used directly when included through a
manifest
/assets/foo/widget.js # not used directly when included through a
manifest
/assets/foo/images/click.png
This would make the package available in application.(css|js) as a simple "require
foo"
How best to configure rails for this? Should assets/(stylesheets|javascripts|images) be
magically considered "global" or should the initializer for sub-paths under
assets be dropped altogether, leaving it to the user to organize assets how they see fit?
(Also, currently there's that somewhat confusing mismatch between app/assets and
public/assets, where app/assets is organized into subdirectories for
javascripts& stylesheets, and public is not -- defaulting to just assets as
the config path instead of assets/* could fix that.)
Are there any established usage patterns I'm missing, or should Rails consider
something to organize this better by default?
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
