Blaise NG

October 7, 2008

Today we had a brainstorm session about the possibilities for layout in Blaise NG. We have been making prototypes in WPF for some time, and it is time to tie things together, and make some decisions. The general idea is that we can reuse the current concepts, but upgrade them to the 21st century. The main part of the discussion focused on whether it is possible to remove layout sections from a bla-file, because we feel that these sections don't belong in a data model. The idea is to put layout statements in a different file. Layout can then be edited graphically or in an editor, by changing the layout file. The question is: will it introduce problems if we handle layout in this way. For now, we are going to go ahead and store layout information in a different file (which means: convert existing bla-files into new ones).
We also discussed newpage instructions in the layout section. The general consensus was that newpage instructions are used to accomplish some sort of grouping. We discussed the possibility to assign a fieldpane to a block field. Such a fieldpane would have to have placeholders for all fields in a block. Discussing this further, we found that we would also need to have a way to describe the behaviour of such a group.

For instance, suppose we have the following piece of code:

DATAMODEL Test

BLOCK BOtherSpecify
 FIELDS
  Color: (red, green, blue, other)
  OtherColor: STRING[10]
 RULES
  Color.ASK
  IF Color = other THEN
   OtherColor.ASK
  ENDIF
ENDBLOCK

FIELDS
 OtherSpecify: BOtherSpecify

LAYOUT
 AT OtherSpecify FIELDPANE fpOtherSpecify

ENDMODEL

This shows the idea that we tie a fieldpane to a block question
The definition of fpOtherSpecify would have to include placeholders for both Color and OtherColor
Furthermore, we want the field OtherColor to be focused the moment we select 'other' in the Color field. This type of behaviour is something that we would want to specify in the defintion of fpOtherSpecify

To be continued...