Item9665: Problems using or understanding ADDTOZONE

Working on Item9030 I learned that ADDTOZONE{"head"} has a couple of problems:

• If you try to remove the scripts (for a print template) by "voiding" it (RENDERZONE{"head" format=""}), you also loose the css If you mean script and not head, then that is a bug - PH, because you don't have control over items within the zones
• Items are added to the same zone - but how do you know which zones are defined? (head, script, sarahpalin)
• If you set the required param, you also need to know the name of the zone I don't think so? ADDs are only sorted within each zone. Cross-zone dependencies aren't possible, unless {MergeHeadAndScriptZones} is enabled (legacy support option)

In head you have 3 object types:

1. meta
2. javascript
3. css

It would be much easier if we define these as preferred zone names for head:

1. meta
2. script
3. style

Then templates can write RENDERZONE{"meta"}, RENDERZONE{"script"}, RENDERZONE{"style"}, and hiding them by not having that particular RENDERZONE in a sub template.

Authors are still free to create other zones if they like, but these will be the preferred (and documented) ones for head.

I think we need to get this done before 1.1 and it becomes a real mess.

-- ArthurClemens - 13 Sep 2010

I agree, but I never got any feedback on the zone renaming task. You should be able to "void" script zone as-is though - if not, we have a bug.

I have gone to great lengths to keep compatibility with old ADDTOHEAD conventions. Think carefully about the change you're suggesting - we would have to re-work a lot of stuff to get CSS dependencies into a dedicated zone; extend {MergeHeadAndScriptZones} to cover the new zones; and more testing. We need 1.1 now. Do the new zones in 1.2.

For now, let's try to focus on the problem of voiding script zone.

-- PaulHarvey - 13 Sep 2010

Among other things, I think we need a DOCTYPE zone/ID, but also a way to get the value without flushing it eg. Templates/plugins could "know" the doctype is html5 and adjust output accordingly

-- PaulHarvey - 13 Sep 2010

Why do you want to remove the javascript from a print template? They don't hurt. Instead, there are pdf/print backends that do execute javascript before finally rendering the page. So better leave them in. Other than that nulling a zone using %RENDERZONE{"myzone" format=""}% is a neat trick. I never ever thought of removing javascript.

Some basic assumptions and clarifications about the zone concept:

1. The only zones granted to exist are script and head.
2. Javascript must be added to the script zone only.
3. Anything else - like CSS or META - is added to the head zone.
4. Never ever add javascript to the head zone
5. Never ever anything else but javascript to the script zone
6. The only need for dependencies is among CSS or among JS. Only these have a real world demand for linear ordering constraints among their own kind.
7. There's no real world demand for establish a dependency between CSS and JS or CSS and META or JS and META.
8. Zone script always is rendered after zone head anyway. So any ordering constraint of JS on CSS is fulfilled intrinsicly.
9. Dependencies expressed via the requires establish linear ordering constraints within the anatomy of the html page.
10. Such an ordering constraint like ADDTOZONE{"X" id="A" requires="B"}% can be refrephase as "for zone X: if there is a B, then A is rendered after B=". This constraint is evaluating to true if either =B does not exist or A comes after B.

Think of the head zone as the catch-all bucket in the head of the html page. This is what the old ADDTOHEAD was minus Javascript which is moved to the end of the html head into the script zone for performance reasons.

I don't see any action required on this but item other than clarification of the concept.

-- MichaelDaum - 14 Sep 2010

why are zones so hard to get? - perhaps because the documentation is lacking essential details.

• The only zones granted to exist are script and =head= Should be added to optional, comma-separated list of the names of zones that the content should be added to. Defaults to head.
• Javascript must be added to the script zone only. and Never ever add javascript to the head zone- this is a much stronger requirement than Normally you should add CSS [...] to the head zone, and Javascript <script> markup to the script zone.
• Anything else - like CSS or META - is added to the head zone. - not yet documented
• Dependencies expressed via the requires establish linear ordering constraints within the anatomy of the html page. - the doc talks about zones: Foswiki uses the requires parameter to resolve the ordering of dependencies within a zone and this is what I have observed.

I will try if these guidelines work - perhaps some code needs an update. And this needs to be documented.

-- ArthurClemens - 14 Sep 2010

Now that I read VarADDTOZONE I understand your confusion. There where a series of missleading comments and examples. Cleaning up.

Arthur, please let me know of VarADDTOZONE is clearer now.

-- MichaelDaum - 22 Sep 2010

Perfectly clear now. I've changed the summary and mark this as closed.

-- ArthurClemens - 22 Sep 2010

Commenting is disabled while not logged in