cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Woody and round trip of parameters.
Date Wed, 30 Jul 2003 17:21:32 GMT
Marc Portier <> writes:

> Hunsberger, Peter wrote:
> > Marc Portier <> asks:
> > 
> >>I can't see a need for a field that should be 'calculated
> >>automatically' AND be editable at the same time.
> >>(I tried though)
> >>
> >>>Thoughts ?
> > 
> > We have a couple of weak use cases for this:
> > 
> > 1) Normally a medical protocol phase might take 14 days, however in 
> > unusual cases it might take longer or shorter.  Thus, if 
> someone gives 
> > us a "phase start date" we might want to automatically 
> calculate the 
> > "phase end date" as start + 14 days, but allow the end user to 
> > override the calculated amount if needed.
> thx for this,
> this time I'ld have to concede that the double requirement emerges...
> only bad thing is it produces also a decission conflict:
> suppose at init we have start-date set at 12/8 and by default the 
> end-date at 26/8
> now the thing is that we cannot make a distinction between the 
> following two cases
> 1/ the user is changing the start-date to 4/8 AND expects the 
> end-date to follow up to 18/8
> 2/ the user is changing the start-date to 4/8 AND the end-date to 
> 12/8 (and would hate that it jumps automatically up to 18/8)
> the only way out I see is by using javascript on the client
> - either submit-on-change of the start-date value
> - or copy the calculation method over to the client to be 
> performed there when start-date changes, but not when end-date 
> changes

In our case we do use JavaScript and an onBlur of the first field.
However, you could also handle this by only calculating a default if the
2nd field is left blank.  However, that likely requires round tripping
the form back to the user a 2nd time for verification of the calculated
fields: not something every work flow can handle...

> (javascript on the client is something we will need to give some 
> thought anyway... maybe we can remember this case until then)

You really need to support it at least at the optional helper level: Eg.
if you have JavaScript then no round trip is required, otherwise the app
still works but you have more round tripping (or other similar
compromises in usability).

> > 2) The same thing happens with medication: normally the # of units 
> > prescribed = the # of units taken, however if the patient spits up 
> > something or refuses something then perhaps the # units 
> taken might be 
> > less.
> > 
> here I get the feeling that it could be solved by setting the 
> value only upon loading of the form, afterwards the two fields 
> are no longer connected and are to be changed independently
> (if my feeling is wrong it probably falls under the previous case?)

Likely so, we have a pharmacy system that can provide # of units
dispensed.  A protocol data manager may then use nurses notes to
determine units taken at a much later point in time.

> > So, yes, I'd say there are probably lots of cases where we 
> would take 
> > advantage of such a capability if it was available, but we probably 
> > wouldn't miss it if wasn't possible...
> > 
> I hope this to be the case for client-side javascript in general 
> (but it is probably just a matter of time before the 'can be 
> missed' are to be turned into 'unacceptable for a full 
> featured...' :-))

Yes, to stay competitive as a framework you really need to support
JavaScript on the client side at least as an optional feature.

<snip on function language discussion/>

View raw message