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 _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

That also means that depending on the max-length, the attributes would have to guard their values against line breaks (that you can have in a text area and not in a text input)…. Not sure if that'd a real problem in practice… what about c) add an additional metadata flag to the attribute definition that can be set for the attributes that must be represented in a text area. Heiko, wont' we have the same question with other types of input (e.g. time input to represent timeout, etc.)

> > As food for thought, we also discussed the addition of another ModelType.TEXT. I kind of like that idea. If the rule is that a ModelType is all that is provided for layout hints then we should think long and hard about every UI type we will need. ModelType.DATE comes to mind. Note that I'm not making a slippery-slope argument here. I think the number of these we really need is finite. I think we would need to answer two questions: 1) What are all the types we need? 2) Is just using ModelType enough or would we need a layout hint attribute anyway?

On 1/23/2013 7:22 AM, Heiko Braun wrote: > > > The question is: What are "layout" hints? Agreed. What exactly are they? I see two things that are needed to automatically generate a full UI from the data model. The first is to understand all the types we are dealing with. That part is relatively easy and it's probably almost complete. Maybe we just need TEXT and DATE and one or two more. The harder thing we need is an indication of relationships. For instance, go to CLI GUI and go to /subsystem=logging/root-logger=ROOT/. Right-click on "handlers" and choose the "write-attribute" operation. It knows that the value of "handlers" is a list so it dutifully brings up a list editor. But if you click on "Add" you see that it only gives you a plain input field. What you really want for all this is a dual-list pick list showing the handlers available to be selected or unselected. But that is not possible right now because the relationship to the defined handlers is not known from the model. I know that Brian has thought about this problem of relationships. It is not just needed for UI. It's also needed to support cascading deletes. I'm guessing that implementation of relationships opens up a whole can of worms and maybe he has decided against doing anything about it. So getting back to the subject of layout hints, if relationship does not become a core part of the model then perhaps it should be implemented as a hint that is only there for the sake of the UI. > If layout hints are anything UI specific, they don't belong into the > core model. The core model should remain client agnostic. It doesn't > make sense to add UI specific elements that don't have a meaning in > other contexts (i.e. CLI). With regard to this, I would prefer model > elements that work across contexts, yet allow us to cover the use > cases of most clients that work on the model. ModelType.TEXT and other > suggestions (ModelType.DATE) fall into this category. > > On Jan 23, 2013, at 1:11 PM, ssilvert(a)redhat.com > <mailto:ssilvert@redhat.com> wrote: > >>> >>> As food for thought, we also discussed the addition of another >>> ModelType.TEXT. >> I kind of like that idea. If the rule is that a ModelType is all >> that is provided for layout hints then we should think long and hard >> about every UI type we will need. ModelType.DATE comes to mind. >> >> Note that I'm not making a slippery-slope argument here. I think the >> number of these we really need is finite. I think we would need to >> answer two questions: >> 1) What are all the types we need? >> 2) Is just using ModelType enough or would we need a layout hint >> attribute anyway? > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev