using #node_slot in navon snippets

At MTU, they have some “global links” at nav_top, and I link them to a new slot in NavTree. In the navon snippets, I call #node_slot($nav.root…) to render the links.

Now, some of their templates are like P-Home, which does not use global template. In those type-specific template, I reuse some of the navon snippets and call #slot(‘rffNav’ …) directly.

This does not work well for AA. I got empty top and left panel in the AA interface.

If I comment out the #node_slot calls in the navon snippets, everything goes back to normal.

The only workaround I can find is to always use global template - call #slot(‘rffNav’…) in global template, not local template, where the navon snippets have #node_slot($nav.root…) calls.



I think it would help if you could post the code, both working and not working.


I have reproduced the problem with the attached rffSnEiNavTop snippet.
This snippet makes a #node_slot call to render the List slot in the NavTree. Preview is fine, but AA fails to load the top and left panels.

Here are the steps to reproduce:
a) Add rffList slot to rffSnNavonLink
b) Edit the EI NavTree, and simply add some titlelink snippets to the rffList slot
c) Import the attached rffSnEiNavTop. This snippet replaces the EI logo with a #node_slot call to render the list slot.
d) Preview the EI home page, which will be ok.
e) AA the EI home page, top and left panels fail to load
f) Now comment out the #node_slot call in rffSnEiNavTop, and AA the EI home page, the top and left panels load and AA behaves properly.

Note that this is a problem only if the type-specific template does not use global template, e.g. the EI home page. You can try to AA a generic page under EI home; it will be fine.

The reason to do this is, customers have some global links that need to be render on every page. But, this won’t work for templates not using global templates.


Type specific templates that do not use global templates must follow a documented set of rules to enable active assembly. Please look at the Home page template implementations of the fast forward samples (EI and CI sites). I am sure it is documented well. JB is out of office for a week still. I will try to get a link to appropriate documentation while you look at the samples.

In the Rhythmyx Implementation Guide, see “Implementing a Page without a Global Template” on p. 175. See also the topic “Embedding Velocity Code in Templates” on p. 78 of the Rhythmyx Technical Reference Manual for more generic requirements.

My example uses the out-of-box FastForward EI home page as is!!!

What I changed is in the navon snippet, not the type-specific page, people!

I see the problem. You are trying to render the generic macro (#node_slot) that is applicable for AA in AA mode and preview in preview mode. Since you are using the macro to render inside the navigation you want to put the AA off for that macro and all macros called inside of it. We do not have such way of specifying.

Your best bet is not use #node_slot macro but write your own that is not aware of AA mode at all.

You may find other alternatives such as adding an auto slot to the home page that uses a custome finder. I am sure you will find one knowing what is going on.

Most of the time, #node_slot is used with a “computed” slot. That is, the contents of the slot are determined programatically (as an Auto Slot, a Navigation slot, etc).

I’d like to suggest that we have 2 macros: #node_slot and #node_slot_aa.

#node_slot would be used for computed slots (such as nav slots) and would not contain any AA functionality.

#node_slot_aa would be used where you needed an additional node, but you wanted AA functionality.

Any comments?


My workaround is to always use a global template. If the type-specific template uses a global template, there is no problem with navon using #node_slot in AA.

I think the application scenario is rather common, global links that are rendered on every page, like the footer. But, end users should only need to specify the links once somewhere (like Navtree), instead of on every page. I think it’s also reasonable if the slot is just rendered in AA, but not editable (because of its global nature).

I guess customer will have to pick a workaround for this…and PSO consultants should be aware of this limitation when trying to implement this scenario.

I’ve filed a bug for this issue: