Bistro Designer Add-in

From Bistro

If your application consists of more than a few controllers bound to a variety of urls, it becomes increasingly difficult to keep track how all controllers are chained together into methods and what urls such methods will respond to. It is also difficult to ensure for every method that controllers can be ordered, that they can pass data to each other, etc.

While some of such conditions can not be checked until runtime, a sizable portion of them can be validated in advance based just on the way your controllers are defined within the applicaiton. The bistro designer is built to do just that. It shows in a graphical form the structure of the urls which your application will process. It also validates your application against a number of conditions and displays the diagonstic information necessary to pinpoint the problem.

Bistro Application Explorer

Currently Bistro Designer is implemented as an add-in for Hill30 WorkflowServer designer. When installed - it integrates into Workflow Explorer tree as a new node - called Bistro.

When Bistro Designer identifies an application as a bistro application - it looks for classes, that implement controller types and extracts information from Bind, RenderWith and other attributes on these classes. After that - it builds bindings tree depending on bind attributes and dependencies between controllers. If a controller has several bindings, or it is bound to a wildcard binding - such controller will be shown in multiple places in the tree - one for each binding matching the controller bindings.

Note, that the binding tree groups the bindings together if it's possible. Because of this some of the nodes of the binding tree will have no controllers under them.

This mechanism does not work when Bindings have different request type.

DefaultController can be seen everywhere because it has "?" Bind.

Under binding node, which has controllers - they are organized into a flat chain, which represents the order of execution, based on resources dependencies, priorities and BindTypes.

Also, all the resources are extracted from these controllers and placed under the same node.

Under each resource there are controllers which provide and consume that resource. provider/consumer role shown by an icon.

Actually - that's all about tree contents. The rest of functionality implemented through context menu.

Errors Node

In case bistro engine cannot create correct binding tree or there are problems arranging controllers in the execution chain - Error is added to the Errors node. It includes controllers and resources involved in the error.

At this time bistro engine detects four types of errors:

• Invalid format for binding URL
• Execution order for the controllers could not be determined because of a resource reference loop
• Resource type mismatch
• Resource has no providers

Context menu description

Context menu works only for Controller node.

It has following items:

• Properties - Shows properties of the selected controller.

Note: Properties of every node can be seen in the properties window, including resources, errors, etc...

• Show Source - Shows source. The same behaviour as double-click.

• Bindings - Shows Bindings list from Bind Attribute of the current controller. Clicking on the binding shows this binding in the tree.

• Provides, Requires and DependsOn - Each shows list of resources, used by the current controller, based on how these resources are marked in the controller.