Unable to start AA on content without global template

Rhythmyx Technical Discussion
1

Our home page does not use a global template, but instead contains everything it needs to display properly in the page template itself.

We are just now trying to use Active Assembly across the entire site, and in testing, we have discovered that AA does not work correctly on pages without a global template.

At first I assumed that there must be some incompatible code on the home page that was breaking AA, but after commenting out EVERY macro, every variable, everything, it still does not correctly display in AA.

The AA page appears to try to load because I get a top bar and a left bar, but they are both empty(no text or icons of any sort). I do see AA icons on my editable fields, but clicking them has no effect.

An error appears at the bottom of the page, out of sight because you can’t scroll the main part of the window, but by pressing the down arrow, or viewing the code, I see this error:


FATAL exception raised: An assert statement failed. The method dojo.lang.assert() was called with a 'false' value. Here's the assert message: Cannot find parent node for field node: id = ["3","10987","787","323",null,"0","0","413","1",null,null,"displaytitle","10978","Title:",null]

In further experimenting, we took a page that DOES successfully work in AA, and in the workbench removed the template’s global template setting from “default” to “none”. Trying to AA that same page will now break in the same way.

Does anyone have any idea what the problem might be? We’ve also tried changing the “Active Assembly format” for the home page template, and while it does seem to change how AA tries to display, it still is not successful in allowing edits. Documentation on that radio button set is extremely sparse.

Thanks,

-Jason

2

Jason,

Does the page template include the #startAAPage and #endAAPage macros required for pages without a Global Template? See “Implementing a Page Template Without a Global Template”, pp. 183-185 in the Version 6.5.2 Rhythmyx Implementation Guide for an explanation. Specifically, see “Adding Velocity to the EIHome Page Template”, p. 185.

RLJII

3

I was missing the #startAAPage and #endAAPage macros, so I added those. The failure mode remains the same, and the error message remains the same, The only change is at the top of the page I get a white document icon that says “page” when I hover over it.

BTW, we have just completed an upgrade from 6.5.2 to 6.7 but I don’t believe that it is related to this problem, as we had tinkered a little with AA before and saw the same behavior.

Thanks,

-J

4

OK, I have some further info on this problem:

I disabled EVERYTHING in the template that had anything to do with velocity, then added the #startAAPage() macro. It finally renders OK. Then one by one, I re-enabled my macro calls to slots and fields until it broke. I narrowed it down to this:

It breaks when I use the #node_slot macro to render a slot, and the template being used to render slot items has a #field macro instead of a #displayfield macro. For example, this call:
#node_slot($nav.root “nav_top” “” “” “” “” $rx.string.stringToMap(“template=utbSnNavHeader”))##
works fine so long as the template utbSnNavHeader only has #displayfield macro calls in it. If I use #field it breaks AA. This is the case regardless of whether or not I put the #startAAPage() call before or after the #node_slot call.

For now I am working because this particular template (utbSnNavHeader) will never need to be used in AA, but for folks who use a generic snippet title link, but need to use it in a node_slot macro call will have difficulty with AA.

At any rate, I’m working now. Thanks for the help.

-Jason

5

Jason,

Looking at your original error, I notice a lot of null values. The #field macro returns an error during assembly if the field has a null value.

See “Field Macros”, p. 87 in the Rhythmyx Technical Reference Manual (Version 6.7 link).

Try adding a dummy value to the null fields and see if that resolves the error.

RLJII

6

We’ve run into a similar issue and it turned out (after much hair pulling) that we had an apostrophe character in the label of one of our fields. Removing that fixed the problem. I would have appreciated it if we weren’t allowed to put apostrophes in there in the first place of course…