Marc Portier <[EMAIL PROTECTED]> writes: > > Hunsberger, Peter wrote: > > Marc Portier <[EMAIL PROTECTED]> 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/>
