(Rod Whiteley and Theresa Locklear, if you’re out there, you have commented on similar issues in the past.)
DXL represents a reference to a shared action as simply . If one exports entire dbs or “well-defined” subsets of dbs, and later imports them, this usually doesn’t present a problem. But if the corresponding shared action with id=‘N’ is not part of the DXL being imported, and the db being imported into does not already contain a shared action with id=‘N’, the shared action reference is going to be broken after the import. The DXL Importer will give an error such as
Referenced shared action(s) not found - creating dummy action(s)
(Note also that if a shared action with the correct ID is subsequently imported or created, the broken reference will now correctly reference that action.)
We would like to rectify this situation in 7.0 but there are ambiguities as to what the correct behavior should be. If you care about this situation, what do you think the correct behavior should be?
Note also that this can happen even when you export entire dbs and import them. When you delete a shared action in the Designer, the references still retain the original code, so they still work. But DXL still emits them as and the code is unfortunately lost. I’ve found that some of the .ntf’s that ship with N/D have these “formerly shared” actions in them. Such instances are not bugs, but they are oddities that DXL doesn’t really deal with as it stands.
Subject: Seeking feedback on DXL issue with shared actions
I would suggest that you go ahead and export the full field with the special tagyada yada
so that if the
is not resolved, the importer can use the value. It adds a bit of redundancy, but makes sense given the way the database stores the information, and it won’t break older versions because the field is new.
Subject: RE: Seeking feedback on DXL issue with shared actions
Gotta agree with Ben here. Export the information that’s in the shared action anyway, and give priority to the single-version of it during the import process. If it can’t be resolved during the import, then use what’s in the form/view context.
Currently, the matching of a shared action reference to a shared action is strictly via its id number. When you stop and think about it, this really kind of assumes that when you import a shared action reference, you are either importing a whole database at once, or you really know/expect that there is a shared action with that id in the db and it is the one you want, which usually implies that you are working with a specific, known db.
What if you want to export a form (just the form) from one db and import into another, different, db? It might have an action that references shared action #42 in the target db. If the target db doesn’t have a shared action #42, the action will be broken. But it’s probably even worse if the target db really does have a shared action #42, because if it does, the action is probably executing something completely different than what was intended.
One thing that we’ve thought about doing for that sort of case is some “fixup” processing in the DXL Importer. It would go something like this. I’m assuming the DXL contains both the reference and the shared action.
if shared action #i doesn't exist in target db
import normally
else
if existing shared action is same as one in DXL
import normally
else
assign new, unused shared action # (call it j) to i
map all shared action refs in DXL from i to j
Subject: So, what happens in the equivalent situation with a form
Rather than thinking about this as a new problem, think of mirroring the old problem. What happens now when a form with a shared field reference is copied into a new db? If the fieldname is already a shared field there, is it used, or is the local definition of the field still used?
Subject: RE: So, what happens in the equivalent situation with a form
Well Ben, you seem to have hopped from actions to fields in this discussion Granted, the issues are similar. But different. As I remember, the way that the Designer deals with shared actions is different from shared fields. But your point is sensible, if I understand it right – i.e. the Designer behavior for cutting and pasting design elements containing shared element references should be the goal behavior for DXL as well.
I’m still concerned about performance, but the only way to decide on that issue is measure it and see how much of an impact it really has. Thanks for the feedback.
Subject: RE: Seeking feedback on DXL issue with shared actions
Thanks for the feedback. What both of you suggest is one of the alternatives we were considering. I was balking at it a little because of the potential performance impact it could have. For example, if a shared action was referenced 100 times, the DXL Exporter (assuming a full db export) would output the code for that action 101 times: once for each shared action reference and once for the shared action itself. Besides adding to the size of the resulting XML, it could significantly affect performance, too. Especially on the Importer side, where LotusScript code is compiled during import. With dbs containing lots of LS code, the LS compiling can use up a significant portion of the import time.
I was considering a variation on what you suggest as follows:
For any shared action reference, the code can be omitted by the DXL Exporter if both of the following are true:
the appropriate shared actions note (i.e., matching the correct language in a multi-lingual db) is also being exported
the referenced shared action exists in that note
A colleague questioned this behavior on the grounds that the entire result of the export might not be imported as a whole. For example, someone might use XSLT to prune out just one design note and then try to import. He has a point, but I’m not sure it’s strong enough to argue against a potentially important optimization.
You can get into API methods/properties to control the behavior, but I tend to resist having arcane settings like this to confuse the user.
Subject: RE: Seeking feedback on DXL issue with shared actions
I don’t think the performance impact is enough reason not to do this. 100 extra times for a field definition is hardly a huge impact compared to the relative size and performance of dumping an entire database, and the potential for harm is great. In times past, these sorts of performance considerations and trying to be “too smart” have led to a lot of problems (e.g., font tables and hide when formulas come to mind). I would strongly suggest that there are more important performance issues to worry about, and that data integrity is just going to be too difficult if you don’t do something like this. I agree that this is much too arcane for a flag to be set, so whichever way you go, go that way.
Granted, the issues are similar. But different. As I remember, the way that the Designer deals with shared actions is different from shared fields. But your point is sensible, if I understand it right – i.e. the Designer behavior for cutting and pasting design elements containing shared element references should be the goal behavior for DXL as well.