Hi Ede, Thanks for the feed-back > On 05.10.2014 17:57, Michael Michaud wrote: >> Hi Jumpers, >> >> I've started to add a big feature for OJ : capability to record macros. > that's really a nice feature! i like it.. > > without looking at the implementation details (you explained it pretty good), > here some questions remarks. first and most important question: > > are all non-interactive (dialogless) recordable now out of the box? Absolutely not. When there is no dialog the adaptation is minimal (ex. DisposeSelectedLayerPlugIn). Don't know if it can be reduced to nothing by adding some code in AbsractPlugIn but the problem is that plugins with or without dialog have the same interface. > >> I did not find a way to implement it without the need to revisit >> each plugin, but I tried to adopt a design >> - which does not break existing plugins >> - where adaptation to make a plugin recordable in a macro is minimal > what happens when during macro recording and a non-recordable plugin is > executed? Just ignored. Until I add a piece of code at the end of plugin execution, the action is executed as before, but not added to the macro. > >> The general idea is : >> - make plugins persistable along with its parameters >> - make plugins runnable from a map of parameters (instead of >> an interactive dialog box) >> To achieve that in a simple way, plugins must be able to store/access >> their parameters through a simple Map<String,Object> >> >> Usually, to make a plugin recordable : >> - you must put parameters gathered from a MultiInputDialog into a map >> - refactor the code so that it accepts the map values as parameters >> instead of named plugin attributes (see changes in BufferPlugIn) >> >> I have tested the concept with several different tools : >> - DisposeSelectedLayerPlugIn >> - BufferPlugIn >> - ViewSchemaPlugIn >> - DataSourceFileLayerLoader >> Some are easy to adapt (ex. DisposeSelectedLayerPlugIn), other >> are difficult (ex. ViewSchemaPlugIn) > i am pretty sure you had a specific use case in mind. could you post a simple > step-by-step list of it that would illustrate a workflow that profits from > automating? Not precisely. I know that OpenJUMP is efficient for prototyping or to do one shot production, but that it has limitations to do repetitive tasks in a production environment. : Exemple (fictive) - get a dataset from a partner - tansform the schema - join the data with our own data to keep data of interest only - save or upload to a database
> >> Any comment about the design is welcome >> Any help to make all our plugins recordable is welcome > that's my main issue with your approach. > A. who is going to make at least most of our plugins recordable? shouldn't > there be a mode where interactive plugins are allowed and come up with their > respective dialog during automation? There is a lot of work to make all plugins recordable but it can be done progressively. I would have liked to find a way to make plugins recordable all at one time but there is a great variety of implementations, and it seems difficult to me. For example, it took me several hours to find where to implement my piece of code to make "open this shapefile" recordable in a macro (not in a plugin). Interesting question about mixing macro and dialog. From my point of view, macro should not open dialog, but I can imagine particular cases where a dialog is needed. It would add much complexity though. > B. our non-interactive plugins (e.g. Copy,Cut,Paste..) should be enabled by > default, if they are not already by your current implementation. I'll give more thought about it. Not sure that you can implement something working for these plugins without interfering with other plugins as execute() may either - do an action or - open a dialog I think if we implement a general method for non-interactive plugin (ex in AbstractPlugIn) the side effect will be that dialog-based plugins will also be recorded and executed by opening their dialog within a macro. This behaviour maybe acceptable, and maybe easy to fix through a new abstract class or interface to differenciate different kinds of plugins. > C. users will assume that they can record _any: workflow when they use this > feature, not just "some" enabled plugins. if we'd go down this road we should > disable (via the Enabled interface) plugins that are not automatable during > recording. Good point > one implementation for C. could be a Plugin wrapper, that implements the > Plugin interface and is instantiated given the original plugin. as _all_ our > plugins are now installed via one routine we could easily wrap each plugin in > this RecordableCheckedPlugin one during the startup. > > RecordableCheckedPlugin could then implement > - an additional EnabledCheck which is enabled during recording and > de/activates the plugin according to it's implemented interface. Seems a good idea. Plugins should explicitely inherit their parent's EnabledCheck in this case. It would also need to check-up/update all plugins or did I misses the point ? > just some quick thoughts ;).. ede Thanks, Michaël > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
