[Antonio Ramirez]

I do not know if any of you have come across the same issue I had:

Having to register a set a set of scripts but they are not rendered in the order I wanted as one to function properly required another one to be registered first. I know that packages should have solved that problem but they didnt in my case.

I believe that if scripts to be rendered, whether single or through a package should have a 'weight' property so to tell the component which one was before than the other. To solve this issue I always end up echoing the scripts the way I wanted and even pre-compressed them and telling script map their replacement. But I think that incorporating a 'weight' attribute will solve it nicely -the idea is not mine but I fully agree with it.

Also, I would like that minifying/compressing/caching should be supported natively.

Another issue is that when I register a script and then I call to render partial a chunck of HTML that requires some javascript that has previously rendered, tend to register/download the script again. Would be nice that Yii 2.0 solves this issue by setting a property instead of clearing the scripts before rendering. What do you think?

[jacmoe]

I would like it if I could choose the have the asset manager publish the scripts (stylesheets and scripts) to a fixed directory and then - like Rails - it could perform concatenation, compression and minification.
That would be awesome.

Currently, I do not use the clientscript component much due to the way it publishes assets.
For smaller apps, it works nicely, but if you are really keen on performance, it's not.
We usually end up with 40ish scripts per page, which is way too much.

[yiqing95]

Antonio Ramirez, on 14 October 2011 - 08:57 PM, said:

I do not know if any of you have come across the same issue I had:

Having to register a set a set of scripts but they are not rendered in the order I wanted as one to function properly required another one to be registered first. I know that packages should have solved that problem but they didnt in my case.

I believe that if scripts to be rendered, whether single or through a package should have a 'weight' property so to tell the component which one was before than the other. To solve this issue I always end up echoing the scripts the way I wanted and even pre-compressed them and telling script map their replacement. But I think that incorporating a 'weight' attribute will solve it nicely -the idea is not mine but I fully agree with it.

Also, I would like that minifying/compressing/caching should be supported natively.

Another issue is that when I register a script and then I call to render partial a chunck of HTML that requires some javascript that has previously rendered, tend to register/download the script again. Would be nice that Yii 2.0 solves this issue by setting a property instead of clearing the scripts before rendering. What do you think?

the js files 's order is truly a problem , the weight idea is great , and the dependency declaration also is an way . give every js file an alias or id then if some js file need another js file loaded first it can declare it use the former js alias or id;

[jacmoe]

The order is not a problem if you set up the dependencies properly.
What I do is tell clientscript that I want all scripts at the end of the page, and it is intelligent enough to figure out what needs to be loaded first.

[Antonio Ramirez]

Yeah, dependencies are there to solve the problem, but didn't work for me when I tried to use CGoogleAPI together with some 'home-made script'. Nevertheless, even though dependencies are great, I think it will speed up a bit more sorting an attribute than backward identifying and order script dependencies.

[jacmoe]

What would be nice is if Yii could automatically combine and compress/minify scripts.
I tried almost all of the various extensions for that purpose and none of them works.
All scripts for which I don't use a CDN should be globbed into one script to save requests.
This is one of the things which Yii is severely lacking IMO.
Take a look to how Rails deals with that.

I've started to just deactivate the publish function for all the extensions I use, and do it manually.

[mindplay]

On a related note, I'd prefer to see a client-script manager in Yii 2.0 that doesn't rely on "black box" magic filtering of the view-output.

I don't like how it magically inserts things into various locations in the document. I'm never keen on things that supposedly "just work", because it's never transparent to newcomers how or why that stuff works.

I'd prefer to see explicit calls in the layout-view to render the head-scripts, body-scripts, etc. - when you're looking at the view, you can see what's being rendered and why. There's no mysterious process you need to understand.

There's also no superfluous overhead from search and modifying (potentially large) rendered documents on the server-side before you can return them.

On that note, perhaps even better would be some kind of simple document-abstraction - an object that represents the returned HTML document, on a high level, not like a full DOM or anything. But this object could carry around things like title, meta-tags, keywords, embedded and inline scripts and CSS, menus, breadcrumbs, etc.

I think this would make more sense than attaching things to the controller-instance. Things like menus and breadcrumbs are sort of intermediary - they're not really just "view", and they're definitely not "controller", they're more like "document", in the sense that they're an abstraction of content that is going to appear in the generated document.

Having a "document" abstraction would also be helpful for testing and diagnostics - especially in conjunction with what I suggested a while back (somewhere on this forum), that action-methods ought to return a "response" object rather than just rendering raw output. Maybe the "document" abstraction would actually be a subtype of the "response" type, I'm not sure...

Anyhow, I digress - but I'm really hoping to see more meaningful and transparent abstractions, and less magic, around the whole request/response/document management in 2.0.

[qiang]

Quote

I'd prefer to see explicit calls in the layout-view to render the head-scripts, body-scripts, etc. - when you're looking at the view, you can see what's being rendered and why. There's no mysterious process you need to understand.

This is in our plan. One main problem is that in layout there could be widgets that register head scripts. So we will still need to play some magic to deal with this issue.

[mindplay]

qiang, on 18 June 2012 - 01:28 PM, said:

This is in our plan. One main problem is that in layout there could be widgets that register head scripts. So we will still need to play some magic to deal with this issue.

Why not just make layouts a separate thing from views entirely?

If a layout is just a document skeleton (head, meta-tags, css/js links, body tag with a content-placeholder) and doesn't even support widgets, the problem goes away.

That's how I use Yii currently - I have one view that implements the document skeleton with absolutely no content, menus, breadcrumbs or anything of the sort. I then have actual layout(s) that define things like navigation, headers and footers - if I use widgets in those, they will always be rendered prior to the document skeleton being rendered. My skeleton view never has any widgets...

(come to think of it, what I called a "document skeleton" here, is actually just the view for the "document" model I described above...)

[jacmoe]

It sounds like a layout organizer.
It's a good idea.

Personally, I am not using the script manager much - I prefer to do this manually as it gives me full control.
I look forward to see what Yii 2 brings.