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

[Brian Stansberry]

I haven't decided against doing anything about relationships. My team is 
quite busy with immediate tasks. Describing relationships is definitely 
an important thing for the future; AS 8 or 9 depending on how quickly we 
want to get 8 out.

Thank you for listing the kinds of information you think is needed to 
generate a full UI from the model. I would like to see a full or nearly 
full list like that before we get too deep into how to implement 
providing each type of information.

On 1/23/13 7:18 AM, ssilvert at redhat.com wrote:
> 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 at redhat.com
>> <mailto:ssilvert at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat