I somewhat regret using ModelType as the type for the "type" metadata in
the resource/operations descriptions. The descriptions are a higher
level construct than DMR itself and the meaning of the metadata is
somewhat different from the meaning of ModelNode.getType(). Using the
same thing for both leads to a temptation to push stuff into DMR that
doesn't belong there.
A new ModelType will create wire format issues. For us to consider that,
the new type would need to be solving some problem intrisic to DMR
itself, not a problem that exists at a higher level.
On 1/23/13 2:23 AM, Heiko Braun wrote:
Right, it might have slightly different semantics.
As food for thought, we also discussed the addition of another
ModelType.TEXT.
It could support:
- the distinction of the input type (text, text area)
- multi-lines
- different character sets when stored as CDATA
IMO this would be more reasonable then simply adding "layout" hints as
additional attribute meta data. But I am not sure about other
implications, i.e. compatibility guidelines of the wire format.
On Jan 22, 2013, at 5:25 PM, Jeff Mesnil <jmesnil(a)redhat.com
<mailto:jmesnil@redhat.com>> wrote:
> 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.)
_______________________________________________
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