ASP.Net Client Dependency Framework

michielvoo

Jun 5, 2012 at 4:25 PM

I want to load some scripts in the <head> and some other scripts just before </body>. If I just register scripts with a <CD:JsInclude> then they will all be combined.

jfajt

Jun 18, 2012 at 3:12 PM

Exactly the same problem here. The library seems to work only with 1 CSS and 1 JS per provider, which is really not enough for some cases. One option would be to create separate providers for both cases & register the files explicitly with particular providers.

Shandem

Coordinator

Jun 20, 2012 at 4:43 PM

The new Placeholder provider allows you to specify the exact location of your CSS or JS files. If you would then like to have even more control over your scripts like having them render in 2 places, you'll need to override the PlaceHolder provider and handle this yourself. The way you would do this would be to assign the scripts you want in the head to a particular group such as group: 1 since they should come first, then everything else you can assign to group: 2. In your new provider you would just check for each group and render them into the corresponding placeholder.

This will require some work on your end to get this provider working unfortunately. Any reason you need the scripts just before </body> ? Perhaps you can just wrap the script that fires there in a $(window).load(function() {..... })); call ? would be pretty much the same thing.

jfajt

Jun 21, 2012 at 8:37 AM

Thanks for reply !

The reason for rendering scripts at more places is that we didn't decide yet to use deferred scripts, and thus need almost all of them at the end of page body to not block rendering of the page. Unfortunately we also need the Modernizer library to enable HTML5 elements to be stylable via CSS in older browsers. This has to be included in head of the page for the internal hack to work for IE. There might be also other libraries which must be included in head due to some proprietary reasons.

Actually I went exactly the way you describe, just using MVC. So I needed to split scripts into groups and ensure the RenderPlaceholder method includes group in the temporary placeholder comment, and also the replacement items which would be rendered instead of this comment later need to be filtered according to group in GenerateOutput method. This way we have to control the groups manually, but are able to render JS at more places in page / view.

Still, this is not enough for our site and maybe for many others ;-) If you look at some "page component", it is usually composed of some backend logic, HTML markup, CSS & JS. JS is usually "static" file, which contains the main client-side logic, and sometimes you need a "dynamic" initialization part of the script included just after the static file link. This "dynamic initializations" have in most cases to be ordered in the same order as the static counterparts. This dynamic initializations are for now not covered by ClientDependency. I agree it is more difficult than implementing the file links though.

Another thing is ordering of those static JS files when working in a bigger team - it may get frustrating for each developer to remember all priorities and client-side JS dependencies when working on same project. The idea which I'm currently implementing is to have a configuration file with client-side dependencies described, which defines groups, priorities, etc. So when a new file is required, you have to go into this config & add the file in proper place ( order of files in config means priority ). Priorities of libraries do not usually change from page to page. So the developers in the team have to remember only an ID of the dependency file in config and include it by this ID into the page. All other bound dependencies are included automatically then.

I think including such functionality would make your library even greater than it is now ;-)

Shandem

Coordinator

Jun 22, 2012 at 2:29 PM

Sounds really cool!

There's been other people asking for a configuration approach as well, maybe not in this concept but all ideas are welcome!!

And we should definitely support a more dynamic approach to rendering scripts/links as you suggest since people may require full control over this.

Updating...

Can I separate scripts into two <script> tags?

Text Formatting

Lists

Quotes

Code

References

michielvoo Jun 5, 2012 at 4:25 PM	I want to load some scripts in the <head> and some other scripts just before </body>. If I just register scripts with a <CD:JsInclude> then they will all be combined.

jfajt Jun 18, 2012 at 3:12 PM	Exactly the same problem here. The library seems to work only with 1 CSS and 1 JS per provider, which is really not enough for some cases. One option would be to create separate providers for both cases & register the files explicitly with particular providers.

Shandem Coordinator Jun 20, 2012 at 4:43 PM	The new Placeholder provider allows you to specify the exact location of your CSS or JS files. If you would then like to have even more control over your scripts like having them render in 2 places, you'll need to override the PlaceHolder provider and handle this yourself. The way you would do this would be to assign the scripts you want in the head to a particular group such as group: 1 since they should come first, then everything else you can assign to group: 2. In your new provider you would just check for each group and render them into the corresponding placeholder. This will require some work on your end to get this provider working unfortunately. Any reason you need the scripts just before </body> ? Perhaps you can just wrap the script that fires there in a $(window).load(function() {..... })); call ? would be pretty much the same thing.

jfajt Jun 21, 2012 at 8:37 AM	Thanks for reply ! The reason for rendering scripts at more places is that we didn't decide yet to use deferred scripts, and thus need almost all of them at the end of page body to not block rendering of the page. Unfortunately we also need the Modernizer library to enable HTML5 elements to be stylable via CSS in older browsers. This has to be included in head of the page for the internal hack to work for IE. There might be also other libraries which must be included in head due to some proprietary reasons. Actually I went exactly the way you describe, just using MVC. So I needed to split scripts into groups and ensure the RenderPlaceholder method includes group in the temporary placeholder comment, and also the replacement items which would be rendered instead of this comment later need to be filtered according to group in GenerateOutput method. This way we have to control the groups manually, but are able to render JS at more places in page / view. Still, this is not enough for our site and maybe for many others ;-) If you look at some "page component", it is usually composed of some backend logic, HTML markup, CSS & JS. JS is usually "static" file, which contains the main client-side logic, and sometimes you need a "dynamic" initialization part of the script included just after the static file link. This "dynamic initializations" have in most cases to be ordered in the same order as the static counterparts. This dynamic initializations are for now not covered by ClientDependency. I agree it is more difficult than implementing the file links though. Another thing is ordering of those static JS files when working in a bigger team - it may get frustrating for each developer to remember all priorities and client-side JS dependencies when working on same project. The idea which I'm currently implementing is to have a configuration file with client-side dependencies described, which defines groups, priorities, etc. So when a new file is required, you have to go into this config & add the file in proper place ( order of files in config means priority ). Priorities of libraries do not usually change from page to page. So the developers in the team have to remember only an ID of the dependency file in config and include it by this ID into the page. All other bound dependencies are included automatically then. I think including such functionality would make your library even greater than it is now ;-)

Shandem Coordinator Jun 22, 2012 at 2:29 PM	Sounds really cool! There's been other people asking for a configuration approach as well, maybe not in this concept but all ideas are welcome!! And we should definitely support a more dynamic approach to rendering scripts/links as you suggest since people may require full control over this.