| RE: [corona-dev] ProjectContainer Definition updates |
|
-
Should I
regard container structure as flat? -
*No,
we still want to show the relationship of container to its related-containers* -
How such
structure will be presented in the UI? -
*One
way to do this is to build the tree on demand in other words at first the view
shows just the container and nested below it is its list of related-containers
with the tree control plus sign (+). When the user clicks on the plus
sign beside a related-container at the time of the click the user interface
retrieves the related-containers of the selected container. I have seen
user interfaces use this approach. This approach allows you to display
cycles, the user can keep going through the cycle but eventually they tire of
it and realize they are cycling through the same items. Ideally, the user
interface should alert the user to the cycle.* -
In such
approach should we leave inside context-container schema the element
related-containers (or subcontainers) of type context-container – nesting
context-containers inside context-container is a tree approach – what do
you think? -
*This
confusion was caused by me not noticing this before in the Schema: The
subcontainers (related-containers) should contain a list of container-uri
not context-container elements. So to retrieve a related container you
must do another projectOpen passing the container-uri* From: The name of subcontainers can be changed
to related-containers – this is not a problem of course. However I have some questions: -
Should I
regard container structure as flat? -
How such
structure will be presented in the UI? -
In such
approach should we leave inside context-container schema the element
related-containers (or subcontainers) of type context-container – nesting
context-containers inside context-container is a tree approach – what do
you think? Edyta |