Hi David, About 10 years ago I wrote an application that acted as a data maintenance front-end for SAP. It was similar in scale: ~1600 unique information elements that a application manager could use to assemble (sub) forms. There was a state machine which handled workflow and visibility of (sub) forms. It could easily act as advanced survey application too. I used Lotus Notes as the backend which generated XForms for the client side.
Now if I decided to rebuild that application in Apache Isis I would create two domains: one that contains the core entities of the business: customer, user, application, etc and another domain which represents dynamical forms: field, collection, subform, form, rule, etc. The toughest part is the representation. When an Apache Isis application starts it inspects the domain and builds a metamodel of that. A viewer, wicket or RO, transforms that into HTLM or JSON. In this case the domain objects are dynamic so the metamodel information cannot be created upfront. But it might be possible to create it on the fly based on the defined rules and give the viewer a generated pojo to store the collected data in [1]. As far as I know there is currently no formal API to read en write to the metamodel. Dynamic forms might be a good use case to create one. HTH Cheers, Jeroen [1] http://blog.javaforge.net/post/31913732423/howto-create-java-pojo-at-runtime-with-javassist On 26 July 2015 at 03:38, David Tildesley <davo...@yahoo.co.nz> wrote: > Hi, > I am looking for some ideas around how ISIS could be helpful in the > following Use Case. N.B. For non-disclosure reasons, I have to mask the > real problem domain however at the same time try and give you a sense of > what it all about and the degree of complexity. > UC1. "Apply for 'XYZ'" > N.B. 'XYZ' in truth has many variations ('XYZa, XYZb, XYZc, ...) which > differ substantially in the information that must be collected from the > Applicant(s). There is only a very small subset of information that is > common. > 1. The Applicant(s) (individual(s)) core details (name, contact details, > dob, identity document number, ...). Depending on the type of 'XYZ' a very > large set of additional information about these parties must be collected > (e.g. educational qualifications, military history, job history, ...)2. > Depending on the type of 'XYZ' and the answers to previous questions, > information about other Parties ("Organisation" or "Individual") must be > collected.3. The system needs to be reactive to the user input. The user > should only be presented with the relevant forms question/input that comply > with the rules for the 'XYZ' type and context (their answers to previous > questions that may trigger another set of questions).4. The system should > group questions into multiple input forms rather than have one large > form.5. The system should allow the user to "navigate" between the > collection of forms until the "OK to submit" rule is satisfied, only > displaying the relevant form questions for the 'XYZ' type and context. > There over 1500 information elements in the superset and it is likely that > even for the simplest 'XYZ' type (single party), at least 50 information > elements will be required. There will be collections in some cases (e.g. > "job history"). > The rules while many, are not complex (no calculations) and focused around > "If the user answered "yes" to this question then ask them to complete > another section of information." Some rules will apply to multiple 'XYZ' > types. I > ISIS allows us to hide/unhide, enable/disable properties, objects, etc. > dynamically. It's just a question of the rules. Coding the rules would be > difficult to maintain because of the size of the data set and the number of > 'XYZ' types (About 10 main types, with each type having several variations). > From a domain model perspective, there is : > A "Party" component which has Party details, Party relationships, contact > details. fairly standard stuff > A "XyzApplication Lodgement" component that is centered around a > Moment-Interval archetype called "XyzApplication" which as you might guess, > has a large number of MI-Detail class/object (e.g. JobHistory). And it has > a large number of Role archetype class/object that are roles played by > "Party" wrt "XyzApplication". > Any thoughts on how and what for the rules management and present "smart > form" would be appreciated. > N.B> If you think you might like to answer this, there is no urgency for > answers - if I don't see anything for a few weeks, I will try again :) > Regards,David. > >
