TeamSite/LiveSite 7.4.1.x - change in behaviour of TeamSite render context

Hi All,

Just thought I'd put this here in case it's of use to anybody.

I've noticed a change in behavior from TeamSite/LiveSite 7.3.1 to 7.4.1 (technically I'm testing on 7.4.1.1, which is Update 1) in regards to page render mode context. This is in regards to components.

In 7.3.1, RequestContext.isRuntime() would be true when the page was rendered on a LiveSite server. RequestContext.isPreview() would be true when the component was viewed on the TeamSite server in any of the following contexts:

Page preview
Page edit
Component preview

This was at the time a bug, in that Page edit should not be identified as preview, which I worked with support through, and their update seems to have arrived sometime before 7.4.1.1. However, its introduced new bugs which breaks compatibility with our existing code.

With 7.4.1.1 on the LiveSite server both RequestContext.isRuntime() and RequestContext.isPreview() are false. On TeamSite both RequestContext.isRuntime() and RequestContext.isPreview() are true for Page preview, and both are false for Page edit and Component preview.

Unfortunately, this breaks a lot of our components that relied on those 2 properties to determine what to show (we display different output to users (editors) on TeamSite to our final version.

However, their fix does appear to make the ContextMode class correctly identify the EDIT context, so now to correctly determine the mode you should use ContextMode.getMode().name() which has the choices: RUNTIME, PREVIEW, EDIT, GENERATE_HTML and EMBEDDED.

Based on the list above the following are the current modes:

Page render (LiveSite) - RUNTIME
Page preview (TeamSite) - PREVIEW
Page edit - EDIT
Component preview - EDIT
Generate HTML - GENERATE_HTML (though I've not actually confirmed this)

Just an FYI for anyone upgrading and who leverages those isPreview()/isRuntime() methods in their component code. I've raised a ticket with support as well.

Find more posts tagged with

Comments

Rick Poulin

With 7.4.1.1 on the LiveSite server both RequestContext.isRuntime() and RequestContext.isPreview() are false. On TeamSite both RequestContext.isRuntime() and RequestContext.isPreview() are true for Page preview, and both are false for Page edit and Component preview.

.....wat? That makes no sense at all. Ugh.

Thanks for the warning. We're on 7.3.2 where the behaviour of those methods is definitely consistent with previous, so the change must have appeared in 7.4.x.

nipper

Have you filed a bug ?

I wonder if they are deprecating isRuntime/isPreview in favor of ContextMode.getMode().name()

claudiag

With 7.4.1.1 on the LiveSite server both RequestContext.isRuntime() and RequestContext.isPreview() are false. On TeamSite both RequestContext.isRuntime() and RequestContext.isPreview() are true for Page preview, and both are false for Page edit and Component preview.

I can only assume that this was a bug that made its way in somehow. It makes no sense at all. Have you opened a case at all?

Garth McMillan

Yes, the case number is #1231450 in case anyone wants to refer to it.

There's no Deprecation attribute on either method at the moment, so I'm not sure whether they are planning to deprecate them - though I suspect it's just a bug.

At the moment, I'm going through all our component code changing RequestContext.isRuntime() to RequestContext.getMode() == ContextMode.RUNTIME and RequestContext.isPreview() to RequestContext.getMode() == ContextMode.PREVIEW || RequestContext.getMode() == ContextMode.EDIT (For backwards compatibility, because previously The page edit mode also reported itself true for isPreview()).

shameem

This one certainly helps us as before upgrading to 741 as our most of the code consists of "isPreview" function.

If you get to know any updates like deprecation/patch/fix, let us know. Appreciate that.

Garth McMillan

Just to close off this thread, this is the final outcome from support:

... I've filed a defect report (ref# LST-10783) for our engineering team to review the behaviour of the 2 methods.

The defect report will go into a pool of reported issues where the engineering team will review as part of their development cycle. In the report, I've requested the engineering team to confirm the actual return value of the 2 methods and if they are changed or depreciated, the details should be included in the documentation so that everyone is aware.