Bad idea to modify Widgets from with STV?

[tmiranda]

I've been thinking about how to make my MultiUser plugin compatible with as many other plugins as possible. One possible way is to dynamically modify the STV widgets using SetWidgetName() during the ApplicationStarting hook (or even in the start() method in the Implementation class), but I'm wondering if this is a bad idea.

In the MultiUser plugin I've created an API that replaces many of the Sage core APIs. For example, instead of using GetFavorites() the STV invokes tmiranda_mus_API_getFavorites(). I did some experiments and it turns out to be very easy to scan all of the Widgets and replace all occurrences of the core API with my methods.

So is it a bad idea to do this? I hope not because if I can get this to work properly I can make the plugin compatible with practically all plugins

Tom

[GKusnick]

That sort of thing used to be considered perfectly legitimate for an STVI to do in its STVImported hook. People don't implement STVIs that way very much anymore, with all the new tools that have emerged. But in principle it would still be possible. The problem would be making sure your import happened last so you could catch any new widgets introduced by other STVIs.

Obviously that's why you'd rather do it in ApplicationStarted. But I think you'll find that if you do it there, you're going to leave the STV in a dirty state so that it will be constantly prompting the user to save it (which you definitely don't want them doing).

The other thing to consider is that a blanket replace of all uses of GetFavorites() might not be appropriate. There might be legitimate cases where a plugin wants access to all favorites, regardless of who they belong to or who's logged in. (A scheduling plugin might be an example of this.)

On the other hand, there might be calls in Java code that ought to be changed, but you won't be able to find them with a widget-based search-and-replace. This could result in inconsistent behavior in plugins that use a mix of widget and Java code.

[tmiranda]

Greg,

Thanks for the insights.

If I should not put the code in the ApplicationStarting hook, where should it go? And how do I avoid leaving the STV dirty state or how do I suppress the "STV has been modified" message? If editing Widgets was the "old way" of importing, there must be a way to do it correctly, right?

To avoid "blanket replacements" I planned on using a .properties file with a simple grammar to specify what to replace and where NOT to do the replacement. Then as I find incompatibilities with plugins I can just update the .properties file rather than update the STVi and/or .jar. I'm not sure if this is possible, but it will make an interesting project.

If other plugins call the core API from within their own java code there is nothing I can do about it. I know my system will not be foolproof, but it will work with many plugins (I hope).

[GKusnick]

Originally Posted by tmiranda

If I should not put the code in the ApplicationStarting hook, where should it go? And how do I avoid leaving the STV dirty state or how do I suppress the "STV has been modified" message? If editing Widgets was the "old way" of importing, there must be a way to do it correctly, right?

I believe the only "correct" place to do it without triggering the "save changes" prompt is in the STVImported hook. Under the V6 import model, the merged STV+STVIs did in fact get saved, clearing the dirty status. Under the new V7 model, there's presumably code in the core to clear the dirty status after all plugins have been loaded, but before ApplicationStarted fires. So really your only chance to do it without running afoul of the dirtiness issue is in STVImported. I know that's not a very satisfactory answer, but I think it's probably the best you can do right now without changes in the core.

[tmiranda]

Originally Posted by GKusnick

I know that's not a very satisfactory answer, but I think it's probably the best you can do right now without changes in the core.

I'd rather hear a correct unsatisfactory answer than an incorrect satisfactory answer

[tmiranda]

I took a look at the manual and it says the hook is triggered when an STVi has been imported using the ImportSTVFile() method. I'm going to assume that that's how the Plugin Manager loads STVi's.

I'm thinking I can use that hook to scan the STV each time an STVi is loaded as long as I'm careful not to edit the same widget multiple times. So each time the code is called it will first check the existing STV (to make the changes to the widgets that were loaded before my plugin) and then check the new widgets for things that need to be changed.

It's not real efficient but I think it's worth a shot.

[Narflex]

Originally Posted by tmiranda

I took a look at the manual and it says the hook is triggered when an STVi has been imported using the ImportSTVFile() method. I'm going to assume that that's how the Plugin Manager loads STVi's.

I'm thinking I can use that hook to scan the STV each time an STVi is loaded as long as I'm careful not to edit the same widget multiple times. So each time the code is called it will first check the existing STV (to make the changes to the widgets that were loaded before my plugin) and then check the new widgets for things that need to be changed.

It's not real efficient but I think it's worth a shot.

There's a call in the core that imports an STVi into an STV. As part of this call, it will execute the STVImported() hooks once the Widget import is done. The ImportSTVFile() API call is not used by the core at all (it's very rare for the core to actually use one of the API calls, it only ever does it for RPC purposes where the client needs to ask the server something). So if you're trying to replace that to modify the behvior, you will be out of luck.

The mechanism that clears the dirty flag is in the code that loads the STV, then imports any enabled STVI plugins, and then clears the dirty state of the STV. There is no other way currently to clear that dirty state.

The biggest problem you'll run into doing what you outline here is what Greg mentioned where Java calls into the API would not get replaced by your logic (and there's really no way to replace those). So weird inconsistencies may result from your modifications.

[tmiranda]

Jeff,

Thanks for the clarification. I have no intention of modifying the ImportSTVFile() API, I was just trying to understand how things are done to see if what I do want to do will have any adverse consequences.

Two questions:

1. If I modify the STV during a STVImported() hook, will that cause the dirty flag to get set or not?

2. When the ImportedWidgets are passed to the STVImported() hook have they already been merged into the STV or will they be merged after the STVImported() hook is complete? I'm assuming it's the former but hoping it's the latter, because if it's the latter I can (hopefully) modify the Widgets BEFORE they get merged into the STV and that should solve my "dirty flag" problem.

Tom

[GKusnick]

Originally Posted by tmiranda

1. If I modify the STV during a STVImported() hook, will that cause the dirty flag to get set or not?

Jeff already answered this in his second paragraph above:

Originally Posted by Narflex

The mechanism that clears the dirty flag is in the code that loads the STV, then imports any enabled STVI plugins, and then clears the dirty state of the STV.

Any dirtiness that happens during STVImported is cleared after all the imports are done.

Originally Posted by tmiranda

2. When the ImportedWidgets are passed to the STVImported() hook have they already been merged into the STV or will they be merged after the STVImported() hook is complete?

If by "merged into" you mean linked into the widget tree, then the answer is neither. The whole purpose of STVImported is to run the STVI code that links them in. So no, they are not yet linked in when the hook fires, and no, they will not get linked in by some other code after the hook returns. It's up to your hook code to do the linking, or it won't get done. Obviously the widgets themselves have already been instantiated in that STV before STVImport fires, and that's enough to dirty the STV. But it's moot since the flag gets cleared anyway per Jeff's post.

I think the real sticking point is that you seem to be assuming that the STVImported hook in your STVI will fire when some other STVI is imported. I don't think that's the case. I think (but can't swear) that yours fires just once, when your STVI is imported, and then the hook and the code underneath it are deleted before the next STVI is imported. At least I don't see any evidence of STVImported hooks persisting in the STV beyond the initial import.

[Narflex]

Originally Posted by GKusnick

I think the real sticking point is that you seem to be assuming that the STVImported hook in your STVI will fire when some other STVI is imported. I don't think that's the case. I think (but can't swear) that yours fires just once, when your STVI is imported, and then the hook and the code underneath it are deleted before the next STVI is imported. At least I don't see any evidence of STVImported hooks persisting in the STV beyond the initial import.

Greg is correct here. When an STVI is imported; the core instantiates all of the Widgets in the STVI and then adds them to the Widget set in the currently loaded STV. Then it searches through all of the NEWLY imported Widgets, looking for any Hook type Widgets named STVImported(). Then it invokes each of those that it finds. Because of this, there is no way to intercept the STVImported hook unless you actually modify the STVI that is being imported itself.

[tmiranda]

Originally Posted by Narflex

Greg is correct here. When an STVI is imported; the core instantiates all of the Widgets in the STVI and then adds them to the Widget set in the currently loaded STV. Then it searches through all of the NEWLY imported Widgets, looking for any Hook type Widgets named STVImported(). Then it invokes each of those that it finds. Because of this, there is no way to intercept the STVImported hook unless you actually modify the STVI that is being imported itself.

Thanks Jeff and Greg. I was misunderstanding how the mechanism worked.