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?