cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Woody and round trip of parameters.
Date Wed, 30 Jul 2003 15:43:19 GMT

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 

(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 
( 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 Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message