Refactor Guvnor UI: A customizable and plugable UI

1: The terminology "Knowledge Bases" needs to be configurable. And it needs to be pre-configured with pre-installed perspectives, for example Drools perspective and SOA perspective. In Drools perspective, we will continue to call it "Knowledge Bases". In SOA perspective, I am not sure yet what terminology to use, maybe "Service Bases"? Anyway this wont be a big issue. The name is configurable, so its the choice of end users to decide the best term to use based on the context.

Question: If the name is configurable, and assume the name configuration is stored in a file somewhere, how can we make sure this works with i18n?

2: The terminology "Packages" needs to be configurable. And it needs to be pre-configured with pre-installed perspectives. In Drools perspective, we may want to rename "Packages" to "Modules". In SOA perspective, we may call it "Services".

3: Supported asset types need to be configurable. And it needs to be pre-configured with pre-installed perspectives. Following info are required to configure asset types:

What asset types are supported in this module/package(or container/folder or whatever term you want to use) for this specific perspective.

The type name.

Type icon

Associated asset editor. So that when you click the asset, we know which editor to show.

As there are always new types ppl want to support, we should allow users to register new asset types. They need to provide following information: name, icon, asset editor. The process of registering new asset types should be done through UI.

Update: Done (GUVNOR-1494). Below is an example how we configure asset editors for Drools perspective in drools-asseteditors.xml:

2. Domain specific editor: This is the editor that contains domain specific information. In Drools perspective, it includes following sections:

Drools package specific actions:

Package configuration.

Package builder:

Module builder (package builder) is a plugable mechanism that knows how to build a module for a specific domain (Drools/Jboss ESB etc). The builder knows how to validate, how combine and assembly assets, how to generate the deployment unit (jar/war etc) for the target domain.

In the future, we will have a section called package deployment. The idea is that this section shows which servers/containers this package has been deployed. Runtime statistics. Deploy/Undeploy.

Update: Done (GUVNOR-1279)

Refactor Asset Editor

Current asset editor:

All assets will have two editors:

1. Generic editor: This is the editor that contains non-domain specific information. Includes:

Non-domain-specific actions: Save/Delete/Copy/Promote to Global

MetaData editor

Description

Discussion

Dependant: Who depend on this asset.

Dependencies: Not sure about this yet. To make things simple, we do not want to allow assets depend on assets, at least not on the build level. By saying "not on the build level." I mean the inter-asset dependency relationship is not used by module builder. Though we can still have a dependency section in asset editor so that we can do change impact analysis (it is called soft dependency, see http://community.jboss.org/docs/DOC-16350 for details).

Lifecycle Management:

Feed/URLs:

2. Asset specific editor: Each asset may have its own specific editor.

Update: Done (GUVNOR-1279)

Perspectives:

Besides pre-installed perspectives (Drools/SOA etc), users can create/define their own perspective through UI. Perspective definition can be exported and imported as a certain format of file. Basically it works like below:

1. There is a view to display already installed asset types for the current perspective. Information displayed includes:

Asset type

Asset icon

Asset specific editor

Asset specific "New Asset" widget

2. Type name, icons, java classes etc can probably be archived into a jar. The process of registering/installing new asset type is done by uploading a jar file.

Development path proposed:

As we will be working on the drools-guvnor master, to not break anything, I propose we take a step-by-step approach:

Step 1: Create a generic Asset editor. Move anything that is not asset-specific to this editor. Then move anything asset specific to the asset specific editor. So one asset normally consists of two editor views.

Step 2: Create a generic Package editor (Module editor). Move anything that is not domain-specific (Drools package specific) to this editor. Then move anything specific to Drools package to a Drools package specific editor. So one Package normally consists of two editor views.

Step 3: Investigate how to write a custom asset editor and how to plug it into Guvnor.