Gentlemen, This path has been down before by others. In practice the problem is the limitations imposed by resources -- few will plug in editors or build new ones. Now what I think would be interesting, and in the past there were a few attempts (maybe the time is right -- Blaze is partially doing this), is a 'meta editor'. Basically a GUI builder for rule maintenance applications. ART Enterprise had one of these years ago, but it was ahead of it's time and the technology wasn't ready. Being able to rapidly put together an rule maintenance application for business users would be a great tool for promoting adoption. Perhaps this architectural approach is a first step, but by itself I fear it will have little effect on overall uptake of drools. Just my $0.02    - Steve Quoting Michael Neale <michael.neale(a)gmail.com&gt;: > Hi All. > > Looking at a refactoring of the Guvnor Editor stuff to make it more > "pluggable" so others can more easily create and reuse editors for > given artifact types (file types). > > Really in principle is is simple, and close to what we have now: > > * An editor is responsible for showing a given artifact type. > * An editor will be launched by guvnor when someone wants to view that > file type > * An editor can implement certain interfaces in which case it can be > injected with events/other things it may need automatically > * All editors will subclass GuvnorEditor > * An editor registry (currently EditorLauncher which is hardcoded) > will not what opens what etc... > > See attached sketch on how this may work... > > The benefits mean that editors can be very loosely coupled. > > Thoughts ? > > > -- > Michael D Neale > home: www.michaelneale.net > blog: michaelneale.blogspot.com > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.