[jboss-as7-dev] Attribute meta-data: max-length

[Jason Greene]

I am unsure about the compatibility implications. Would it not be better to just introduce a relative UI hint in our description model (e.g. something like UI-INPUT-SIZE = small, medium, large)?

It seems like there could be cases where a value would have a large max length, but we don't want a text area?

On Jan 22, 2013, at 10:12 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> 
> 
> 
> -- 
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat