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...
- Roger Linssen's blog
- Login or register to post comments