[OPEN] [#694] ResourcePlaceholder is now not needed, but it may not follow best practice when loading your own CSS files?

This is a followup to a comment Daniil noted in this thread about resource placeholders not being needed anymore:
http://forums.ext.net/showthread.php...ack-isn-t-used

First, it is good to know that it is not needed anymore.

The only consideration I had about that is if people want to add links to their own stylesheets, they will end up after the script references to the Ext JS scripts. From a best practice point of view, it is considered better to have all the styles at the top as scripts can block download of other resources (unless they are async, which doesn't make sense in apps like Ext JS based apps).

This can result in perceived download performance degradation (given the Ext JS scripts are large as well, albeit likely to come from a CDN, or local Intranet, or often the browser's cache). This is because it can result in a flash of unstyled content - or in the case of Ext.NET, partially unstyled content as the main theme will have loaded first. So it will look like a delay for the user for all the styles to be fully applied.

However, from an Ext.NET point of view, I can understand that there isn't a better solution other than perhaps the following

• Put Ext styles at top as is now, but Ext JavaScript at end of head (with risk of people inserting their own JS referring to Ext which will end up before the Ext scripts)
• Detect the first script tag in the head an place the Ext ones before that one (leaving it up to developer to get it right, which may be fine)
• Leave it as is (good in cases where custom stylesheets not needed) and let developers use the resource placeholder when needed.

Maybe the last option, leave as is, is good as it will be least change for you and everyone who already uses it, but augment with an example in the Examples Explorer of the ResourcePlaceholder and "document" its optional need and scenarios in the example?

Also, is it even worth consider that maybe in Debug mode, perhaps log something to the browser console (like Sencha does for Ext JS, with a warning) that a resource holder for scripts should be considered if you can detect that there are other stylesheets being added in the head? (May not always be easy to detect, not sure.)

Also, I just realized all your examples have a link to an CSS file, examples.css. In this case too you will end up with script tags before your custom CSS file. While in many cases the perceived download problem might be negligible, perhaps to demonstrate best practice it is worth the examples explorer examples using resource placholder where another CSS file link is detected?

Or, maybe it is enough to just have a mention of the resource placeholder feature in the Examples Explorer and discussing when you would use it, and when you do not?

Just had another idea/feature request:

Maybe the Ext ResourceManager can be extended to take in a list of CSS stylesheet files and JavaScript files to add to its loader.

This can then be combined (bit like ASP.NET Bundles - or maybe use Bundles behind the scenes???) to create a single stylesheet link and a single JS file. When the resource manager (or web.config) has debug mode set, then don't bundle up but have each file loaded separately (which is incredibly important too, for debugging!).

I've increasingly found myself using ASP.NET Bundles optimization instead of embedded resources for each custom class I may have, as I often forget to recompile the project to see a change/tweak in a CSS or JavaScript file applied (which is also a bit annoying as it is often very small tweaks from time to time!).

If Ext.NET uses ASP.NET Bundles optimization itself to serve Ext JS/Ext.NET and our own JavaScript/CSS files) then in theory the ordering/dependency of what to load can be controlled more effectively, perhaps?

Programmatic access to this would be important (at least for me) because I create separate JavaScript files for locale strings in a separate folder based on some locale naming convention (en-GB, zh-CN, etc etc) so being able to add the correct paths would be useful.

Maybe an Ext.NET 4 thing? :)

Hi Anup,

I don't have anything to answer yet. I should come up with something soon.

I just realised you have ResourceManager's RegisterClientScriptInclude instance method, and the static ResourceManager.RegisterGlobalScript method both of which can take a script URL as a parameter.

E.g.

Code:

---

<%@ Page Language="C#" %>
 
<!DOCTYPE html>
 
<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        ResourceManager1.RegisterClientScriptInclude("key1", "Test1.js");
        ResourceManager1.RegisterClientScriptInclude("key2", "Test2.js");
        ResourceManager1.RegisterClientScriptInclude("key3", "Test3.js");
 
        ResourceManager.RegisterGlobalScript("Test4.js");
    }
</script>
 
<html lang="en">
<head runat="server">
    <title>Resource Manager with client script includes</title>
</head>
<body>
    <ext:ResourceManager ID="ResourceManager1" runat="server" />
</body>
</html>

---

This is great. Although at the moment it writes out each script added this way as its own script tag. Perhaps there is an option here to combine/minify/gzip these into one script tag.

There are similar methods for styles.

So perhaps these could be enhanced to result in one style and one script tag. That way the order may not be an issue as styles would always be added to the HTML before the script tag.

This could be the way to internally even incorporate and re-use ASP.NET's Optimization/Bundles capabilities, possibly? (Because it helps detect when dependent scripts have changed etc, and saves you figuring out all the subtleties and complexities!)

Some flexibility/trade-offs could be useful. E.g. in some cases it may be okay to combine absolutely everything if the first time download hit is acceptable. In other cases it may be that the Ext JS/Ext.NET JavaScript (and CSS) are more stable compared to the application specific CSS/JS so in that scenario offer the ability to generate one combined script tag for Ext.NET/Ext JS js and another for the application's (same applies to CSS).

In fact, there are so many possibilities here that this could be quite a change (and therefore reusing/incorporating ASP.NET Optimization/Bundles feature could be useful)! So maybe this is something for the roadmap?

Currently I use ASP.NET Bundles myself for all my own JavaScript/CSS (some 50 JavaScript files, for example - I am trying to follow Sencha's suggestions of one class per file, and given they can be bundled, makes it easier to maintain this). I create a separate bundle that combines the core scripts with the current user's locale (as we support more than one language - something else for you to consider if you do this!)

One final thought (for now!) is that perhaps you can offer to at least combine all your Ext.NET scripts/css with the Ext JS scripts/css to minimize initial page downloads? (Other than where it makes sense to load on demand, such as your plugin resources, perhaps, and where people choose to use embedded resources, etc.)

Hi Anup,

Quote:

---

First, it is good to know that it is not needed anymore.

---

Just to clarify. I said it is not needed anymore in the exact scenario that you had in the that thread. I didn't meant there is no use of ResourcePlaceHolder at all. Sorry for not being clear.

Quote:

---

The only consideration I had about that is if people want to add links to their own stylesheets, they will end up after the script references to the Ext JS scripts. From a best practice point of view, it is considered better to have all the styles at the top as scripts can block download of other resources (unless they are async, which doesn't make sense in apps like Ext JS based apps).

---

Yes, it is a good scenario to use a ResourcePlaceholder.

As for examples.css in our examples. Well, the content of our examples is mostly (or just entirely) produced by Ext.onReady() script which goes after examples.css anyways. We will probably leave as it is for now. Though, thanks a lot for the suggestion.

As for all your other suggestions. We appreciate it a lot. Yes, there is a room for improvements and it would be very nice to have it all built-in. To be honest, I am not sure we will ever be able to implement it all and when if we do. We already have a couple of related issues regarding resources:

• Improve managing of UX resources
• Pre-gzipped resources

Basing on your suggestions, I decided to create a more general Issue: Enhance API/functionality of managing of CSS and JavaScript resources

Unfortunately, I cannot provide you with any time frame.

I am moving the thread to the Feature Requests forums.

Hi,

Thanks for looking into this. What you is fine. I too expect it is not trivial to introduce these changes, so moving to a feature request to consider for future is fine.

I am personally happy with my current set up (your resource manager for your scripts/styles plus my own ASP.NET Bundles for all my scripts/css, and using resource placeholders to control where they all go).

Maybe one possibly smaller improvement is you could combine your Ext.NET and Ext JS script (and CSS) tags into one tag to minimize the http requests. But even that may require code changes that require a fair bit of retesting etc, so again, nothing urgent.