To provide some context:
In subsystems coded using current best practices, the definition of a
string attribute is created using a SimpleAttributeDefinition.
static final SimpleAttributeDefinition FOO = new
SimpleAttributeDefinitionBuilder("foo", ModelType.STRING).build();
By default, that attribute will be constrained to having a min-length of
1 and a max-length of Integer.MAX_LENGTH.
Support for null/undefined is separate:
static final SimpleAttributeDefinition FOO = new
SimpleAttributeDefinitionBuilder("foo", ModelType.STRING)
.setAllowNull(true)
.build();
You can also constrain the max-length of the string by passing in a
custom validator to override the default:
static final SimpleAttributeDefinition FOO = new
SimpleAttributeDefinitionBuilder("foo", ModelType.STRING)
.setAllowNull(true)
.setValidator(new StringLengthValidator(1, 10))
.build();
With Heiko's proposal, if you didn't specify a StringLengthValidator or
the one you specify didn't pass a max-length param to the constructor,
the default would change from Integer.MAX_LENGTH to something smaller
(e.g. 245, 1024). If you needed something larger you'd need to modify
your subsystem to declare it.
On 1/22/13 9:56 AM, Heiko Braun wrote:
We have the case within the UI that the client needs to distinguish text input types. I
most cases a simple text inout is sufficient, but in some cases a text area is more
appropriate (i.e. datasource>new connection sql). I am wondering, if the max-length
attribute could be used for it.
It's currently tight to ModelType.STRING, which is fine.
In order to show the expected results, we would need to decrease the default value for
max-length, to something smaller (245, 1024). This way we could provide text input for for
anything below that size and text area for anything else.
Some implications I would like to hear your thoughts about:
a) lowering the default max-length might break your subsystem and/or specific clients
b) keeping the current default and doing it case-by-case will result in text input
(opposed to text area) for all String attributes once we switch to a dynamic UI (usability
drawback).
Regards, Heiko
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat