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? > 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? > 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? > 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? B. our non-interactive plugins (e.g. Copy,Cut,Paste..) should be enabled by default, if they are not already by your current implementation. 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. 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. . just some quick thoughts ;).. ede ------------------------------------------------------------------------------ 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
