Changing resource order

Topics: Writing modules
Dec 3, 2011 at 12:48 AM
Edited Dec 3, 2011 at 12:50 AM

Could somebody please hint where I have to look for how to change the order of how the static resources (styles, scripts) are written? I guess it's a placement thing as changing the item order of the resource list has no effect, although ResourceManager.WriteResource() gets called in the new order. (Of course I'm having this trouble with the Combinator module.)

Thanks in advance.

Dec 3, 2011 at 1:05 AM

It's not placement, no. for the included ones, I believe it's the order in which they are registered. For required ones, it's modified by dependency order, so dependencies are included first.

Dec 3, 2011 at 1:16 AM
Edited Dec 3, 2011 at 1:18 AM

Strange, because if I add an item with a name that has previously existed (registered) then it gets rendered where it was previously. To illustrate:

Original order (in the list that's returned from ResourceManager.BuildRequiredResources() and in the output):

  1. StylesheetA
  2. StylesheetB
  3. StylesheetC

If they're deleted an moved around to have the order in the list:

  1. NewStylesheetA
  2. StylesheetB
  3. NewStylesheetB

...the order in the output:

  1. StylesheetB
  2. NewStylesheetA
  3. NewStylesheetB

Calling ResourceManager.NotRequired() on StylesheetB does not help.

This list contains all the resources, dependencies already compiled.

Dec 3, 2011 at 1:18 AM

Maybe I was wrong and it's unspecified. In any case, if you need a specific ordering, you should register your resources and declare dependencies.

Dec 3, 2011 at 12:39 PM

Hmm, when doing in the IResourceManager instance neither declaring dependencies, neither re-using names (or even whole resources by only changing the url) of previously registered resources have an effect. E.g. extending the above example: by changing the url of StylesheetA's url to that of NewStylesheetA, the order of the output is still the mixed up (last) one (and actually the resources with modified urls are not written through StylesheetBindingStrategy Ln 87).

It seems that all the stylesheets are discovered on startup and although resources registered later (dynamically) are written to the output fine, since they go through some different mechanism, they're written always after those that were registered statically.

Dec 3, 2011 at 11:35 PM

I guess it's more efficient to work out the dependency tree once at startup than have to recompose it on every request. Does this have anything to do with Combinator? Maybe there's another way around ...

Dec 4, 2011 at 12:13 AM

Surely it's better to compile all the resources together at startup, I was just after some technique to alter their order somehow. I haven't found one, but I've taken a different approach (yes, this has to do with Combinator as I've mentioned in the opening post :-)) that works: it's a quite primitive one but not only it works, but it's needed anyway.

I asked the question because I wanted to merge combined (unconditional) and not combined (conditional) resources together, but the conditional resources (these were genuinely registered resources, not modified by the module) were always on the top, thus breaking styling. Now the module minifies conditional resources too (and combines them if multiple resources with the same condition follow each other), so this is not an issue anymore.

Dec 4, 2011 at 1:13 AM

Just a note about Placement ... it only *ever* applies to shapes generated from drivers. This is because it's a specific hook passed into BuildShapeContext (from DefaultContentDisplay) that performs the placement lookup. And that is usually only used when ContentShapeResult applies, which is usually from ContentPartDrivers (I've never seen any non-driver code use placement, although it technically could do).

However, I came up with a way to use placement for all kinds of other displays as well as content (e.g. arbitrary admin UIs) which is what the Origami module is about, but even that in no way "automatically" wires up anything to placement, you still have to use drivers.

Dec 4, 2011 at 8:02 PM

Thanks, I always wondered where the placement is processed.