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
(javascript on the client is something we will need to give some thought anyway... maybe we can remember this case until then)
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?)
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...' :-))
BTW, at the moment we're using XPath (actually anything that can be processed by Saxon's evaluate) as the "language" for specifying calculated fields. Don't know if that's possible given the direction you guys are headed or not?
the expression language support in woody is currently the one Bruno first applied into XReporter (http://xreporter.cocoondev.org) there is already some jxpath support (but only in the template files) and there was at least one suggesting jexl (above client-side javascript idea might even suggest using the same language on the server)
I'm quite sure the discussion will come up again in due time, my current feeling is in fact that scripting support inside the whole of cocoon (jxtemplate for instance) could maybe be factored out to a specific script-evaluate-avalon-service-component that can be called from different parts... this would kind of offload the discussion on the woody work and probably bring more consistency among all script-using components in cocoon
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
