Skip to content

Latest commit

 

History

History
141 lines (99 loc) · 5.21 KB

README.md

File metadata and controls

141 lines (99 loc) · 5.21 KB
Raw

NEWSKQL - New Schneider Kalf Questionnaire Language

DSL for Questionnaire Language

Demo

Feel free to try out the DSL editor on the demo website:

http://sp.schneider.click/

So far it only outputs the given questionnaire to a JSON textarea.

Development

Requirements:

Install dependencies:

Only necessary if dependencies changed or first run.

yarn

Run development server:

yarn start

Visit http://localhost:3000

Generating a new parser

Requirements to generate parser

You need a global installation of pegjs to run the parser generator command below:

npm install -g pegjs

Run QL parser generator

After making changes to src/parsing/grammars/ql_grammar.pegts you can run the following command to generate a new parser:

npm run generate:ql

The results will be written to src/parsing/parsers/ql_parser.ts. If the development server is running it will automatically reload.

Tests

To run the tests inside src/test please execute:

yarn test

This will watch all files for changes and execute the tests every time a file is saved. You maybe have to press a initially to run all tests.

Build for production

yarn build

Result will be written into the /build folder

QL Requirements

  • Questions are enabled and disabled when different values are entered.

The type checker detects:

  • reference to undefined questions

  • duplicate question declarations with different types

  • conditions that are not of the type boolean

  • operands of invalid type to operators

  • cyclic dependencies between questions (Forward referencing)

  • duplicate labels (warning)

  • The language supports booleans, integers and string values

  • (possibly also dates and decimals).

  • Different data types in QL map to different (default) GUI widgets.

Requirements on the implementation:

  • The parser of the DSL is implemented using a grammar-based parser generator.
  • The internal structure of a DSL program is represented using abstract syntax trees.
  • QL programs are executed as GUI programs, not command-line dialogues.
  • QL programs are executed by interpretation, not code generation.

QLS Requirements

  • QLS allows you to place questions of a base QL program in pages and sections.
  • Furthermore, you can define default widget types and styles for questions of a particular type (e.g. boolean questions).
  • Such default styles can be overridden on a per widget basis.
  • The execution of a QL + QLS program should be the same as executing the QL program individually, except for where questions appear (page/section), what font-styles etc. are used, and what widget types are used.
  • As widget types you are supposed to support at least: slider (number min max, step is 1), spinbox (for numbers), text (for numbers and strings), yesno-radios, checkbox, yesno-dropdown (for booleans).

The type checker detects:

  • no references to questions that are not in the QL program
  • all questions of the QL program are placed by the QLS program.
  • (default) widget assignments are compatible with question types (e.g. no radio button for integer widgets).
  • you cannot place a single question multiple times.

Requirements on the implementation:

  • You could say QLS defines an "aspect" of questionnaires, i.e. its appearance. The challenge is to implement QLS without (invasively) changing the code pertaining to QL, and without duplicating or reimplementing the QL code. (Copying and/or duplicating is not allowed, but some changes might be needed at certain join points...).
  • The QL code, and especially, the QL ASTs should be oblivious to the QLS code. Think about how you can achieve that.

General

  • Do not forget to take care of keyword reservation: true and false should be parsed as boolean literals, not as identifiers.
  • Add single-line comments (a la Java: //).
  • Add syntax productions for forms, questions, computed questions, types (int, bool, and string) and if-then and. Use string literals for question labels. See the LWC'13 link above for an example questionnaire.
  • if-then-else statements.
  • Add tests to check your syntax extensions.
  • Add AST classes for the provided expression categories, and for you syntactic extensions. Make sure the parser creates objects of the appropriate type.
  • It is unacceptable that there are remnants of dead code, commented out sections, or debugging print statements etc. in the code that you will present for grading.
  • Some way of shipping the answers, exporting the result (although I couldn't find it in the assignment)

Presentation

Technically any platform • Identification (accounts + photos?) • Language + frameworks • Parsing (syntactic analysis) • AST (design) • Static analysis (type check) • Interpretation (rendering) • Styling (QLS) Show no else, no instanceof and no switch Error messages with line numbers (rename weightFishOneA to weightFishOne1)