I found something interesting. Let's say I have 3 extensions, all of which use a js library called cookies.js, which could also be used by a 3rd. party extension.
Since registering the file several times will cause multiple inclusions, I need to check if it's already included, but, since the 3rd. party extension could be using another key, this could be a bit messy if I don't change the source code.
What to do?
Good question.
Unfortunately, I can't think of a good solution for this… Do you have any idea?
One way to solve this is that we specify a common subdirectory (such as "assets") under "extensions", and put asset files under that folder.
The point is, when Yii gets its extensions repo, users hopefully will start to submit their extensions, many of which could have common js libraries. And if there's a [tt]yiiic extinstall[/tt] command, how could this command solve the conflicts? how could the developers coordinate to avoid conflicts?
Yes, I understand the problem here. That's why I was proposing a common assets folder under "extensions".
The rules are like the following:
a single asset file (e.g. js, css, image) is uniquely identified by its file name
an asset package is uniquely identified by its directory name
If extension developers follow these rules, then the problem can be solved.
For example, if your three extensions all use the same "cookie.js", then you can simply drop this file to the common "assets" folder and publish it. If another 3rd party also requires the same js file, he should also drop the file under "assets". Since the file is the same, we can either overwrite or skip the existing file.
The drawback with these rules is that if two files with the same name are having different content, we are in trouble. However, this situation is not very likely because the files that are stored under the common "assets" should be from some open source projects (or for the extensions developed by the same person).
Another way to solve this problem is to use filename-based hashing when publishing an asset file. By doing so, as long as two asset files have the same file name, they will be published with the same URL. I think this approach is better.
I like the ability of Yii to be extensible and sounds nice to have cool extensions that are easy to setup and use…
but… from the documentation:
Quote
Having downloaded the juidatepicker I've found out that if I used jquery-ui for my project or even another copy of jquery with the validation plugin for client-side validation I'll end having many copies of jquery and this is not very optimized.
This is similar to the fact of having dynamically or statically linked executables on linux I think… the first one are more optimized and lightweight but the seconds one can works better among various distributions and or libraries versions…
But maybe there could be a sort of compromise to improve all this in Yii… like having some "libraries-extensions" packages that works like extensions but are not extensions… are for example "tinymce" or "jquery-ui" and so on… so that each extension could have in its properties the parameter "required libs" that require for example "tinymce" version "3.x+" so that if two extensions will have to use tinymce or jquery-ui or whatever and the need the same version, there is no need to provide that requirement twice…
Anyway… I'm new to Yii so in all this I could have been missing something and my message could then lose its sense… in this case let me know and just ignore it; else I'd like to hear what you think about this.
bye,
Giovanni.
Hi Giovanni. There’s already a discussion on this here. Please use that thread for the follow-ups, unless Qiang prefers using this thread 
Virtual DarKness says here:
[quote=Virtual DarKness]I like the ability of Yii to be extensible and sounds nice to have cool extensions that are easy to setup and use…
but… from the documentation:
Quote
Having downloaded the juidatepicker I've found out that if I used jquery-ui for my project or even another copy of jquery with the validation plugin for client-side validation I'll end having many copies of jquery and this is not very optimized.
This is similar to the fact of having dynamically or statically linked executables on linux I think… the first one are more optimized and lightweight but the seconds one can works better among various distributions and or libraries versions…
But maybe there could be a sort of compromise to improve all this in Yii… like having some "libraries-extensions" packages that works like extensions but are not extensions… are for example "tinymce" or "jquery-ui" and so on… so that each extension could have in its properties the parameter "required libs" that require for example "tinymce" version "3.x+" so that if two extensions will have to use tinymce or jquery-ui or whatever and the need the same version, there is no need to provide that requirement twice…
Anyway… I'm new to Yii so in all this I could have been missing something and my message could then lose its sense… in this case let me know and just ignore it; else I'd like to hear what you think about this.
bye,
Giovanni.
[/quote]
You should not use several jQuery libraries, since you’ll end with a js mess 
. You should stick to the one provided with Yii, IMHO. As for the jQuery UI plugins, they are not included with core Yii, but with some of 3rd party extensions. Until now, they haven’t collided, since they’re specific for certain widgets. Qiang is evaluating if jQuery UI could be included in the core in the future, which would eliminate the potential problem of multiple inclusions of the same js library.
Yes, this has been discussed above. This is more a problem of coordination among the extension developers (3 + Qiang currently), plus some glue. Your idea looks nice, and it’s similar (or equal) to the proposal done by Qiang. It would be nice to have something in the repository to glue the extensions (a “javascript commons”) and set some conventions to make use of these common files/libraries. But also, since the users of the extensions have the source code, they could change the inclusions of the js libraries to adjust to their convenience, which could be easier (or not… 
)
Quote
Sorry, I’ve missed that one 
…
maybe the two threads could be merged or this one can be closed…
thanks.
bye,
Giovanni.
Quote
)About jQuery… it was just an example but maybe the tinymce one fits better.
But about jQuery UI I would see it as many “libraries” / “extensions resources” also considering the fact that you can download just some part of them from the website… but that would require also requirements between resources for example the “jqui_dialog” resource could require the “jqui_core”, “jqui_draggable” and “jqui_resizable” resources… 
Then I think starting from a method like:
/**
* @param string $res_name The required resource name/code
* @param float $res_ver The required resource version
* @param int $accept_ver version is accepted if (1=eq.||maj, 2=eq., ..)
*/
requireExtensionResource($res_name, $res_ver, $accept_ver) { // ... }
$res_name will use the codename of the resource and there should be a list on the website of all the available resources with download link and code… just a simple table not a detailed page like the extensions page…
and the $accept_ver parameter would use pre-defined constants like:
define('_AV_EQMAJ', '1');
just my 2 cents…
bye,
Giovanni.
p.s.
resource path could be determined using:
/resources/$res_name/$res_ver_str/ …
the resources folder maybe should not be under the protected one or it will require different .htaccess rules cause for example some tinymce files must be readable by apache… anyway… the $res_ver_str string should be built like 00030010000 if one resource has 3.10 for version number… or something like this… or we could just ignore release versions and use release dates instead (sounds evil hehe) … like 20081229 (this would solve the problem of having different versioning methos between various scripts like you could have 3.1 or 3.10 or 3.0.14 or 3.0.15r1 and so on…)
Hi there, and sorry to reopen this old topic, but I'd like to know if the filename-hash based inclusion have been implemented in 1.0.4 or before. While working with jQuery plugins I've found many which are reused across several projects, being these file collisions a problem.
Thanks.
CAssetManager::publish() has a parameter to allow you publishing a file based on its name only.
Also, CClientScript::scriptMap can be used to set up a mapping between script names and their actual URLs.