Thanks Stephen, I have been doing a little research around XForms and had a
play with Orbeon. I'll look into it more.
Regards,David.
On Tuesday, 28 July 2015 8:15 PM, Stephen Cameron
<[email protected]> wrote:
Hi David,
My two bits worth, I think Apache Isis is the last thing i would use for this
kind of a task. If the information collected is that complex, then trying to
fit in into a relational database via an object model makes no sense. Just use
an XML database and XForms.
There are server-side implementations of XForms that work well, namely Orbeon
and BetterForms, if you want to hide the declarative form logic from users.
For me, its Isis for behaviour and XForms/XQuery for complex data, both are
efficient in their domains of specialisation.
Where the boundary lies is an interesting puzzle to me. There is paper that
myself and another wrote, somewhat on this contrast, here [1].
XForms is efficient as all the complexity that you describe can be done
declaratively via XPath predicates [2]. That said, there is no validating
compiler, so refactoring is a pain for example. Joeron's suggestion of two
domain models might be alluding to that perhaps? But subforms do provide a
means to manage this.
Finally, XForms can be fun too, see [3]
Cheers
Steve Cameron
[1]
http://www.balisage.net/Proceedings/vol10/html/Velasquez01/BalisageVol10-Velasquez01.html
[2] http://lib.tkk.fi/Diss/2007/isbn9789512285662/article3.pdf
[3]
http://exist-db.org/exist/apps/XSLTForms-Demo/modules/form.xq?form=tic-tac-toe.xml
On Sun, Jul 26, 2015 at 11:38 AM, David Tildesley <[email protected]> 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.
