element insertion with custom pseudo class

[PaulHayslett]

My client has a custom framework with many Author actions to insert XML fragments. They also use pseudo classes to modify the display of several elements on a per-element (rather than per-document) level, mostly to show or hide form controls which allow editing of attributes.

They would like to be able to insert an element with a pseudo class set just for that one new element. I'm sure that I can create a Java function to make this happen, but I'd prefer not to, if possible.

I have tried creating an Author action of class ExecuteMultipleActionsOperation which calls two other actions, one to create the element and the other to set the pseudo class. Each action is known to work in isolation. The combined action inserts the element but does not set the pseudo class.

Any hints? Or do I need to drop into Java?

Thanks in advance.

[alex_jitianu]

Hello,

It should work. Does your second action (the one that sets the pseudo class) have an activation XPath? If you have then that might be the cause. All the activation XPaths are tested (wrongfully) at the beginning of the compound action. We fixed this in the current development stream and the fix will be available in version 19.0. So the solution would be to let the second action without an activation XPath. Considering the fact that you are chaining her explicitly after an insert operation, I would expect no side effects.

Please let me know if this was indeed your case. If not, perhaps you can send me a sample framework to reproduce the issue? Or I can send you the one in which I've tested a similar scenario...

Best regards,
Alex

[PaulHayslett]

Hi Alex,

Thank you for getting back to me.

Your possible explanation (that the XPaths are tested only once) had occurred to me as well, so neither sub-action has an activation XPath. Only the top level action.

However, the SetPseudoClassOperation call takes an XPath expression argument to identify the element to act upon. I did occur to me also that this may fail if the DOM isn't updated after the first action (SurroundWithFragmentOperation) is complete. That is, the fragment is inserted and the caret is now inside of it but the editor doesn't know. It can't see the newly-inserted enclosing element yet. Might that be the problem?

My client's framework is huge and gnarly. I'll try to isolate just the broken bits and post.

Cheers,
Paul

[PaulHayslett]

Alex,

AHA! In the course of making up a demo framework, I have discovered the problem. You may wish to enter this as a bug to be fixed in a future release. Or not.

It turns out that the second sub-action DID have an activation XPath: a single line-feed character left over after deleting the XPath which had been there before. Invisible, of course, so it looked to me like nothing was there. But it prevented the second sub-action from firing.

I only discovered this while comparing the raw XML of the framework files to see why my demo framework worked and the original did not. There was just no way to see it in the UI.

I would argue that whitespace before or after an activation XPath is never relevant and so your UI should trim it when storing the expression. Would that break any existing frameworks? I guess it's possible. An action might suddenly become activated that wasn't before. But I'm sure I'm not the only person to have been bitten by this.

At any rate, I'm tucked in now and my client is happy. So we can end this thread.

Thanks again.

Paul