| 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. Each container has a list of related
containers, there is only one kind of relationship, isn't it. In UI, related
containers are displayed as nodes in a tree view after clicking on a container. In the previous architecture we had
the notion of children (subcontainers) and parent. If I understand correctly,
the current architecture is as follows: -
"subcontainers" were renamed to "related containers" -
parent was removed How do we represent both many children
and many parents in the current architecture? What is the difference between the
current architecture and the previous one? Currently, we can trace the relation
forward, but not backward. I assume that the relationship is not bi-directional,
isn't it. Pawel From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Everitt, Glenn -
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 The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. |