On Mon, May 08, 2006 at 09:02:17AM -0700, Jim Busser wrote: > d (or dd) is fast to input and unambiguous, so I disagree it be > disallowed unless you are talking how it be *stored*. I agree that > for the stored freetext value, a digit in isolation is meaningless. Well, when the date time input widget evolves it will support more such patterns be they ambigous or not. I was talking the document content date input for the 0.2 release.
> So I presume now Karsten is talking about defining what is > unambiguous (therefore acceptable) in the *backend* as opposed to > how frontend/middleware code would translate/transform the input > prior to storage? I had thought such a widget would be seen as > desirable on the "functionality roadmap"? Yes. It's already on the roadmap. There is also code in the repository already. And it's used, somewhere, too, I believe. (gmDateTimeInput.py) Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
