Showing posts with label Guvnor. Show all posts
Showing posts with label Guvnor. Show all posts

Wednesday, July 23, 2008

Drools Flow view in Guvnor with GWT Diagram

We now have Guvnor displaying uploaded Drools Flow files. We use the native GWT XML api to read in the XML document and GWT Diagram to generate the diagram. At the moment it's view only, over time we will make it editable - which will sure beat round tripping with Visio that other platforms do.

Tuesday, July 22, 2008

GuvnorNG

Work has already begun on GuvnorNG, which is the next generation web framework for Drools, which will hopefully be delivered next year. GuvnorNG is being written to provide the foundations for the JBoss SOA Platform governance tooling, so we need to make every aspect of it pluggable. So it'll have pluggable viewers and editors, be more flexible on the content types it can store and support dashboard layouts. Mike Brock, the MVELauthor, is the main person behind this at the moment. It's very early stages and Mike is working on the foundations, particularly state management and pluggability. He has made a screen caste so people can see it working, notice at the end how the refresh does not lose any state. You can find the Screencast here.

As always Mike is looking for contributors, it's a very interesting project that can be usable standalone, outside of Drools, for any enterprise to develop their governance software and dashboards with.

Saturday, July 19, 2008

Rolodex Panel Assembly for Guvnor (Anton Arhipov)

In my previous post about integrating rolodex into Guvnor I tried to create the example just with a set of pre-compiled images which are then assembled into drools-guvnor.war. But the real goal is actually to display the pictures stored in Jackrabbit repository for Guvnor.
Now, after some experiments with rolodex and Guvnor, I have a widget where one may upload a picture and display it.

Currently it can accept only one picture per RuleAsset class instance. Therefore the content handler for this asset should be extended to support multiple images per RuleAsset.

RolodexCardBundle images = getImagesFromAsset();
RolodexCard[] rolodexCards = images.getRolodexCards();
if (rolodexCards.length > 0) {
final RolodexPanel rolodex =
new RolodexPanel(images, 3, rolodexCards[0], true);
layout.addRow(rolodex);
}
I have set the hight of the panel manually as the picture was cropped otherwise in the widget. (Don't know the reason yet). getImagesFromAsset() is used for converting the asset's content to the RolodexCard:
public RolodexCardBundle getImagesFromAsset() {
return new RolodexCardBundle() {
ClippedImagePrototype clip = new ClippedImagePrototype(
GWT.getModuleBaseURL() + "asset?" + HTMLFileManagerFields.FORM_FIELD_UUID
+ "=" + asset.uuid, 0, 0, 300, 200 );

RolodexCard card = new RolodexCard(clip, clip, clip, 300, 100, 10);

public int getMaxHeight() {
return 200;
}

public RolodexCard[] getRolodexCards() {
return new RolodexCard[]{card};
}
};
}
I've cheated with the code that composes the RolodexCard, as ClippedImagePrototype's javadoc says:
This class is used internally by the image bundle generator and is not intended for general use. It is subject to change without warning.
But the implementation of ClippedImagePrototype is actually what I need. Probably, if it is really the subject to change at any time, I would rather cope'n'paste this class into Guvnor code base.

TODO:
A heavy part of the work will have to be carried out by the content handler. The content handler will have to support the multiple images per asset and also perform some graphics routines in order to replace the pre-compilation phase implemented in rolodex to adjust images.

Friday, July 18, 2008

Guvnor BRMS and Eclipse Synchronisation

The Guvnor (BRMS) and Eclipse synchronisation tool has made leaps and bounds in progress for the upcoming 5.0 Milestone 2 release. It now has full bi-direction synchronisation of files between Eclipse and Guvnor. A developer can now work locally with a rule, or other Guvnor assets, they can do lots of small commits to their SCM of choice and when they need to can upload or synchronise that asset with Guvnor. Eclipe diff viewing is also supported.

Synchronisation

Diff Viewer

Version History

Tuesday, July 15, 2008

Integrating Rolodex to Guvnor for Image Asset Types

In Guvnor, there are many different widgets that are used to display or edit different assets. One interesting widget is about to be added - a widget that could accept images and display them. For this purpose, rolodex, a widget that can display a stack of images, can be used. Rolodex uses deferred binding for the image generation and animation. Let's see how can we quickly add a new widget displaying some predefined images.

First, create a class, implementing RolodexCardBundle interface (from the rolodex library) and declare a few methods that will return the images (just like ImageBundle described in the book):

public abstract class Images implements RolodexCardBundle {

/**
* @gwt.resource img_3861.jpg
*/
public abstract RolodexCard imgA();

/**
* @gwt.resource img_3863.jpg
*/
public abstract RolodexCard imgB();

/**
* @gwt.resource img_3865.jpg
*/
public abstract RolodexCard imgC();

...

private final RolodexCard[] cards = new RolodexCard[]{ imgA(), imgB(), imgC() };

public RolodexCard[] getRolodexCards() {
return cards;
}
}
Next, to display those images, create ImageSetWidget (or you-name-it) class extending DirtyableComposite:
public class ImageSetEditor extends DirtyableComposite {
// asset and viewer are not used now...
public ImageSetEditor(RuleAsset asset, RuleViewer viewer) {
final Images images = (Images) GWT.create(Images.class);
final RolodexPanel rolodex
= new RolodexPanel(images, 3, images.imgA(), true);
initWidget(rolodex);
}
}
For Guvnor to be able to launch the editor, we have to modify EditorLauncher class:
...
else if (asset.metaData.format.equals(AssetFormats.IMAGE_SET)) {
return new ImageSetEditor(asset, viewer);
...
AssetFormats should be supplied with the new constant for this new type, of course.

To allow user to create such widgets in UI, a new menu item needs to be added.


This means, ExplorerLayoutManger#rulesNewMenu() should be modified
m.addItem(new Item("New ImageSet",
new BaseItemListenerAdapter() {
public void onClick(BaseItem item, EventObject e) {
launchWizard(AssetFormats.IMAGE_SET, "New ImageSet", true);
}
}, "images/rule_asset.gif"));

And last, but not least we need to include the following line in Guvnor.gwt.xml
<inherits name='com.yesmail.gwt.rolodex.Rolodex'/>
Now, after the project has been rebuilt and redeployed we get the following widget on the screen:


Currenly, the widget is displaying a predefined set of images and animates them as we roll the mouse over. So we have now a rolodex-powered widget inside Guvnor. Sounds cool! :)

Now, there are a lot of TODOs to make use of this new cool widget.

  • Menus should be pluggable. So far I knew that the only class that we should generate in order to support adding new rule editor widgets. Without doubt, a user needs a button to create the widget in his workspace, and therefor we should inject the new menu item. I suppose we can generate this part also. Therefore we need to extract the ExplorerLayoutManger#rulesNewMenu() method into a separate class.
    Currently I have an ant task ready to generate a new EditorLauncher class source to plug a new asset type editor. But perhaps, if we have more of these classes to be generated, I'd better add a new ruby script to do this job.

  • Upload of new images. There's no use of this widget if it can redisplay only the predefined set of images.


  • RuleAsset support for images.The images should be supplied via the RuleAsset, i.e. the content should be a class that could represent a set of images.

  • A content handler is required as well.

Tuesday, May 06, 2008

A REST API for Drools

Part of the work for the Drools 5 repository is a Rest API - to allow content to be accessed remotely. The initial purpose of this is to let assets in the repository be synced with files in a developers workspace.

Rest turns out to be a perfect fit, we have the usual verbs:

PUT: update content (create a new version).
POST: create a new asset
DELETE: delete an asset
GET: retrieve asset content, or package listing

All actions are of course in the context of a package - but this is all specified by the url:

http:///api/packages//

So for instance, doing a PUT to: http:///api/packages/SomePackage/SomeAsset.drl will update the content of the SomeAsset.drl.

This may be terribly useful to some, terribly un-interesting to others, but at the very least people should appreciate the ability to get and update content to files/workspace from the repository without error prone import processes.