Shared Actions - best practices? improvements to inheritance in 8?

Is anyone aware of a doc that explains ‘best practices’ when using Shared Actions?

The Design inheritance ‘model’ on them seems to be very different from other design elements and I’ve run into issues when trying to move changes from our Test environment to Production. These include:

  • shared actions turn into regular actions

  • design doesn’t inherit

  • different shared actions show up on a subform’s design instead of the ones that I put on the subform

They still seem like a great design option, but I’m baffled at how to get them to behave when we want to move changes from Test to Production.

Have there been changes to them for 8 that address some of their quirks?

Thanks

Julie

Subject: Shared Actions - best practices? improvements to inheritance in 8?

I had the same problems, here is my interpretaion of how it works and how I worked around, it

Scenario, Updated Mail6.ntf/inotes6.ntf by updating standard notes actions and actions create for the applications.

MY INTERPRETATION OF HOW IT WORKS

I think shared actions are added to Forms/Views by some DOCUNID that each design element has in the Design collections.

So when a Shared Action is DELETED and reAdded, this UNID connection is lost. (The designer tries to keep a copy of the old action and this ends up like a LOCAL action from that point on)

If a new User defined action is deleted, Then in the Forms/Views design information, there is an empty link pointing to the Shared action deleted and Designer finds the closest Action it can repopulate with and this links to some other totally unrelated action.

MY SOLUTION

NEVER delete a shared action to update it, UPDATE the code directly in it.

I had to use inheritance and also these changes had to be inheritable in other Clients mail template

I created a working template by copying the Mail Template,

Then in my working template, I made the changes directly to existing shared actions.

I added the new Shared actions

I then linked the New Shared actions directly to the target forms/views

Now inheritance also works.

Just remember the key point, ONCE A SHARED ACTION IS USED IN ANY DESIGN ELEMENT, IT CANNOT BE DELETED TO UPDATE THE UNDERLYING CODE.

Subject: Shared Actions - best practices? improvements to inheritance in 8?

My own best practices, developed with a previous employer (thanks Rui/NIS), precisely to address the issue you describe:

Shared actions contain only a

@Command([ToolsRunMacro]; “Agent Name”)

All code that needs to be modified is then modified in the agent and not in the action. This also takes care of recompiling issues when Script Code in a shared action uses Script Library code and the underlying Script Library changes.

Subject: Thanks - both of these suggestions will help

Thanks - both of these suggestions will help us plot out a standard.

Julie

Subject: RE: Shared Actions - best practices? improvements to inheritance in 8?

There also is an old-school alternative to shared actions, that seems to be somewhat forgotten by now:

Empty one-line subforms with regular actions.

Subform actions add up in the order the subforms occur on the form. Writing just from the top of my head, I’m not sure if this avoids all the possible troubles with shared actions and you also have to copy over those subforms, when copying forms. But since actions have a real fully-fledged environment on their own in a subform (like subform globals), it should be more robust than standard shared actions.

This also avoids the overhead of calling agents, trading it in for the overhead of inserting subforms (which I never found to be meaningful). You’ll have to load the libraries you need in each subforms, but to the best of my knowledge duplicate loading of libraries is avoided by the client.

There are some limitations, of course, like that you cannot change the order of actions taken from the subform, once you are in the target form. Anyway, I felt like mentioning it as an alternative for special cases.