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@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?