0 Replies Latest reply on Dec 20, 2006 4:14 AM by mjuteau

    Design Question

    mjuteau

      The sample startup kit webapp uses a single, highly dynamic screen to display any task, and any associated form fields and buttons/transitions. Is this the way to go on large business apps? Should the workflow engine drive the entire UI?
      How would we handle more complex UI problems such as different page layouts, pagination, form validation rules, client side stuff (Ajax, etc), navigation, etc - all of this from a single dynamic screen?
      I tried a more conventional approach, where tasks would be mapped to their respective custom screens. However it seems that a task definition, as modeled in the XML graph file, does not have an identifier, other than its 'name' property (a task instance, of course, has an identifier).
      So, it seems awkward to use the 'name' for the mapping. Should I abandon this approach of mapping task definitions to specific screens? Any comments or suggestions greatly appreciated.