On Fri, Jun 27, 2008 at 07:08, Greg Caulton <caultonpos at gmail.com> wrote:
> Thanks to the java reference implementation I have a demo of importing
> archetypes to auto generate forms which have the references to the
> archetype.

Nice. Keep up the good work.

On Fri, Jun 27, 2008 at 07:08, Greg Caulton <caultonpos at gmail.com> wrote:
> One thing I noticed in the conversion that I don't have any way of
> distinguishing between a line of text and multiline text in the
> archetype (I would generate an appropriate pane in the latter case).
> Perhaps not a big deal.

This might be a useful requirement for the current template
specification currently being worked on, or possibly a new kind of
related specification.

I first thought that templates so far had been considered as purely
specifying semantics and that they were not supposed to give hints
regarding GUI rendering. But now I see a parameter "hide_in_ui" in the
class T_COMPLEX_OBJECT found in the draft template specification. (A
similar function is present in the Template Designer tool from Ocean
Informatics there is an option to "hide" elements instead of
constraining them to zero occurrence, in the output file this is
persisted as hide_on_form="true".) Could anybody detail it's intended
use a bit more?

I think GUI rendering hints can be appropriate to specify at the same
point in time as template design is taking place. If the hints are to
be persisted in the template file or in a separate file I guess could
be discussed, keeping it in the file could have maintenance
advantages, but probably has some disadvantages too. Thoughts? (And
no, GUI hints are not appropriate in Archetypes since they are meant
to have a wider reuse and the use cases are not known in the same
detail as for templates.)

In some of our implementation experiments and in discussions with
clinicians a possible need for specifying detail levels in templates
have surfaced. Some elements from archetypes are easy to completely
dismiss or include for the specific use case in mind when designing a
template clinicians will say things like "this will always be needed"
or "this will never be needed". Other things could be conditional and
trickier "you can't have all these details om the form - users would
go crazy - let them show up if i click a plus-button or if i tick
value x was true".

The requirement to use GUI screen area optimally is even more pressing
when using small input devices such as PDAs.

If there was some way of specifying detail level in the template
perhaps using a simple integer (0=default, 1..n=deeper detail with
increasing number) then the same template could better support
automated or semi-automated design of entry forms different screen
sizes etc. One naive/simple but useful way of using the integer could
be to add a "plus-button" for things with detail level 1 and within
that subform have further plus buttons for level 2 and so on.

The "conditional" requirements are trickier and probably needs  more
experimentation and evaluation than can be allowed if a first template
specification should be completed and released within reasonable time
(we all want that). The conditions might also in some cases better be
specified in decision support or workflow  than in templates. Also a
look at the previous work with gradually expanding forms in
Clinergy/Pen&Pad should be considered, I believe they were partly auto
generated from ontologies.


Best regards,
Erik Sundvall
erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579

Reply via email to