[rules-dev] GuvnorEditor refactoring

[Michael Neale]

Requiring a recompile of the GWT bits is fine if that is what is
required, its not uber dynamic what we need, just good clean
interfaces to allow separate lifecycles of editors development if
needed (less toe treading).

Probably would have separate maven projects for each editor I guess
would be a place to start.
It is possibly to do this in various ways with GWT, the simplest being
to have a GWT module for each editor which is referred to in the main
Guvnor gwt config, but that still leaves the launching code etc...



On Fri, Oct 30, 2009 at 11:40 AM, Jervis Liu <jliu at redhat.com> wrote:
> Michael Neale wrote:
>> 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 ?
>>
>>
> Great idea! One question, how do we plug a new editor into Guvnor? Does
> this process require the recompiling and rebuilding of guvnor.war? It
> would be nice if an user can just write a new custom editor then build
> and package the new editor in his/her own environment then drop the new
> editor into Gunvor's deployment dir without changing the guvnor.war.
> This will provide great flexibility to users who want to  extend Guvnor
> with their own file types (artifact types).
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com