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(a)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(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
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat