The easy and intuitive way of designing interactive applications is via visually drawing a flow of screens. VCB allows make use of this approach by representing flow of screens as parts and connections. On high level diagram it shows screens as VCB parts, where inpins represent inputs for the screens (received from other screens or processes) and outpins represent the user actions.

Screens on highest abstract diagram are devices because they are composed from other parts. The VCB implementation of screens will depend if we are developing rich client or thin web client but on top-level diagram the flow will be implementation independent. The interesting idea would be to use the same flow of screens both to generate web and say Java applications only by changing implementations on lower levels. Lets consider web implementation of a certain screen flow.

For web applications screens are web pages. Every web page will represent a VCB device. User perform actions by clicking links of submit buttons on the web pages. VCB diagram will represent that by outpins for each web page device, one per each submit and important links (we don’t need to have all links but only the ones which important to our workflow). Inpins for the web page device will start page generation process. On VCB diagram outpins are connected to inpins, thus every action of a user will bring another screen. One page can send to another page parameters e.g. submitted form field values.

Webpage implementations contain both screen generation and user action analysis part. By screen generation we understand content retrieval and presentation. Content retrieval mostly related with database or other data source queries. It also contains business logic elements. Connections represent sequence of screens driven by user actions.

VCB allows connections to be reconfigured without affecting the pages themselves. It allows usage of best practices in UI development when the controller (configuration in our case) decides the next page and not the page itself. So VCB allows usage of MVC design pattern in a very natural way.

Lets consider an example. We have email system, which has login screen, inbox, and send email. So we have the following web pages: Login, Inbox, ReadMail, Compose, Confirmation and Logout. After login user will get Inbox where he/she can see the list of received emails, can select an email and read it (ReadMail screen), can compose a new mail via Compose screen and can logout and after showing Logout confirmation return back to the Login screen. From ReadMail screen user can deleted mail, reply, forward or compose new mail. From Compose screen user can go to Logout or Confirmation.

In order to perform such functions Inbox has the following outpins: compose, readmail, next and logout and one inpin: show. Pins also have parameters like for ‘show’ pin it will be parameters like user is and page number.

The diagram will look like this:

Now lets consider Inbox screen implementation. The Inbox web page part is a VCB device and as such it contains nested diagram, which inherits terminal pins info from the parent diagram. It means that inpins and outpins for Inbox device on the parent diagram become input and output terminals in the nested Inbox diagram. So the implementation started on the diagram like this:

Show inpin has two parameters – userid and page number (first page by default). The inbox screen content is based on database query, which uses the userid and page number parameters. So we need a Database component with prepared SQL statement, which returns received emails by user id and range (defined by page number). Template generator used to generate the SQL statement using the templates. So the template will be like:

Select * from receivedmail where userid=%userid% and mailId > %startrange% and mailId < %endrange%

Template generator will replace the parameters with the values it receive from Show inpin. The generated SQL will be send to the Database part and it will generate xml as a result. XSLT transformer part used to transform the XML result into html format. In order to configure the behavior constant and XMLReaders are used. Constant parts use fixed values which can be changed via VCB tools or VCB config files, while XML readers uses external XML files. They can be used interchangeably. Constants are easy to use within VCB and change but it could be that there are some external files we need to use (e.g. XSL stylesheets).

Developer sets the path for the XSLT stylesheet in XMLreader part.

SessionStep is responsible for sending the screen rendering to the client browser and accepting next user request and firing an appropriate outpin with url details. We will show this part in more details later.

Controller matched url which encode user's request with its config file and fires appropriate pins.

The basic sequence will look as typical model view controller sequence, when model part will generate the content, view will render it in html and controller will handle user input.

SessionStart and SessionStep Parts

In this approach we need two interdependent components – SessionStart and SessionStep.

SessionStart component initialized with a preconfigured URL (asterisk can be used). Its purpose is to start new session when a user sends the request to this url at first time. It fires ‘Start’ event and doesn’t send response back to the user at that moment but rather postponed it. If we are using servlet it can go into wait mode.

Then the event(s) are traversing between VCB parts till they reach SessionStep.

SessionStep has an inpin called response. Its goal is to send the generated HTML to the client browser and wait for new request. Then it will fire its request outpin. In the servlet implementation SessionStep part wakeups appropriate waiting servlet and pass response to it. Next, it puts in some static table information that this SessionStep is waiting response. When web server got new request from the user it checks session and in the table it checks which SessionStep is waiting for response for this session. It wakes up the SessionStep and pass to it the url and query parameters if any. Schematically it looks like this:

Or in more details:

Dispatcher part is a servlet, which behave like a state machine. It ‘remembers’ from which pin it way fired to send response and fires appropriate pin when got request independently which url is there (as soon as it is within the context of the current server).

If all presentation urls and links will be relative then we can control the flow via VCB diagram, because we will always get request in one place and will decided the next page using VCB links and not URLs. This is the most important benefit of using VCB style, when links on the diagram controls the real flow of screens and not the html presentation.

The behavior is similar to state automata. At every moment user is at the certain state and VCB move him from one state to another depending on his input and other conditions (say time or user privileges).

Another example of interactive web application build on VCB priniciples is shown on the following diagram. It demonstrate sample e-commerce applications.

Testing.

Developer can run the VCB in a step mode. That is he can start a browser with the login url. After submit he will see that some outpins of logout get highlighted and will see event in the event queue. The clicking next will go into inbox part, go next will see the generated XML, next will allow to check the output in html and so on. Developer can copy past html in a browser to start next screens sequence, or can even just create and re-route the event further without using browser any more.