Nico Klasens wrote:
> Pierre van Rooden wrote:
> >Nico Klasens wrote:
> >>I understand Michiels point. It is very hard to make smart editors if
> >>the String datatype answers with undefined on the yes/no-question: do
> >>you like newlines?
> >
> >It doesn't do so now either. You get a pattern and you have to then
> >analyze it. The pattern can technically be anything.
>
> The difference between an input-line and textarea is that you can enter
> \n. The pattern is the only restriction which can disallow this. You
> don't have to analyze the pattern. You only have to ask the pattern if
> it allows a \n
>
> if (dataType.getPattern().matcher("\n").matches()) {
> // textarea
> }
> else {
> // input-line
> }
>
You exactly got my point. How nice to find some understanding in the
world. I was looking for a nice datatype-way to decide between
input-line and text-area. It used to be a check like
'guitype.equals("field")' which of course became inacceptible, because
guitype is kind of deprecated and associated with the name of the
datatype now.
I thought the opposite of 'field' was 'string' (see for exmample the 1.7
news builder), so I figured the logical thing to do was to disallow
newlines for string (I can't help it that it is a base type...). I
didn't realize that people entered newlines anyhow in 1.7, but no
worries, because we can make the pattern 'soft' with enforce='never'.
Well, all in all it's perhaps not yet perfect, imagine that the pattern
is 'Sir,\n\n.*'. An odd pattern, but it allows newlines. But I do think
it is very, very strange to have such restrictions on free text
fields. Perhaps we should not match on \n but on 'getDefaultValue() +
"\n"' or so, but then of course somebody is going to propose
"Sir,\n\n.*sincerely,[a-z]{10}". My proposal is to hope that we're not
around such lunatics :-) And anyhow the only problem would be that
standard editors present a bit unexpectedly an input-line for such a
field...
Michiel
--
Michiel Meeuwissen mihxil'
Peperbus 111 MediaPark H'sum [] ()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
