Closed (won't fix)
Project:
Drupal core
Version:
7.x-dev
Component:
javascript
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
4 Jul 2009 at 21:11 UTC
Updated:
9 Sep 2009 at 23:21 UTC
Jump to comment: Most recent file
Comments
Comment #1
sunOn one hand, you're right that there might be a module that performs heavy actions to alter libraries. Libraries API might be a good example. On the other hand, a module like that most probably has to perform many other additional actions anyway, so it needs it separate caching (and controlled cache flushing) anyway.
Usage of $name leads to a PHP notice here.
Comment #2
sunTagging.
Comment #3
robloach#505084: Add #attached_library FAPI property for drupal_add_library()
Comment #4
robloachUpdates to HEAD, takes sun's note about the $name into account and fixes a namespace issue.
Comment #5
mfer commented/me subscribes
Comment #7
lilou commentedHEAD is broken.
Comment #8
moshe weitzman commentedReally expensive libraries can use own caching. We have to end the cache explosion soon. -1.
Comment #9
robloachMoshe, what about modules that regex a file to find out what version of the library they have? To improve the developer experience (modules wouldn't have to cache the data themselves), as well as improve performance (calling a number of module hooks which could do expensive things like regex an opened file), we could just easily cache the library array.
Comment #10
moshe weitzman commentedNeither of those arguments is compelling. Adding caches rarely improves developer experience. You then have to understand what cache to clear when you are developing and debugging ... Further, the performance gain here is insignificant. It *only* could happen for an expensive operation when its module author cannot be bothered to do own caching.
This is a speculative cache. It might help under certain circumstances that are theoretical. Drupal has enough caches without implementing speculative ones.