|
From: Gerd W. <bir...@t-...> - 2006-02-21 20:18:55
|
Robert Manning wrote: > Glenn, Gerd: > > Just a thought: > > The standard and optional plugins are all available in the installer now. > However, we don't currently have any inter-dependencies between > plugins. If we introduce one, we'll probably want to update the installer > to not allow the user to install one plugin without the plugin that it > depends on. There already is a dependence between the Graph and the Script Plugin. It works like this: If you use the Graph Plugin without the SQL-Script Plugin and if you try to script a table from within a Graph the Plugin tells you that it needs the SQL-Script Plugin to perform this task. Though this is the user list a little hint to the sources: See PluginManager.bindExternalPluginService(). I see the problem you are talking about. But I think it's not black and white. There are several ways to deal with the problem. The ones I see right now are: - Introduce inter-dependencies within the installer as you suggested - Move things to core as you suggested - Tell the user when a Plugin is missing to preform a task. - Declare Plugins as standard There may even be more. I'm not yet sure which one or which combination is best. At the moment I tend to just see how things are going to evolve. Perhaps the users will tell us, perhaps we are going to find out when we go on building SQuirreL's core and SQuirreL Plugins. > > In a related topic, functionality that is common to multiple plugins might > best be moved to core, no? So, if scripting support is required by > multiple > plugins, would it make sense to work out a generic API and relocate it to > FW? See above. > > Rob > > On 2/21/06, *Glenn Griffin* < gw...@co... > <mailto:gw...@co...>> wrote: > > Hi Gerd, > I would suggest that the Designer function not be included in the SQL > Script plugin. My reasoning is that the Designer could become a major > functionality on its own, and putting it in the Script plugin would > have > two negative effects. One is that people who want the Scripts plugin > may not want the Designer and all of its complexity, and the other is > that the potentially huge amount of Designer code could make it > difficult to maintain the Scripts plugin. Glenn, I see your point. The designer dialog I described could be a Plugin of its own. But I still think it would be good if it worked only on one table at a time and if you could invoke it from the Object Tree. Nonetheless, the one who's going to write it will do most of the deciding. Gerd |
