[
http://jira.magnolia-cms.com/browse/MGNLDATA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24945#action_24945
]
Jan Haderka commented on MGNLDATA-88:
-------------------------------------
The part of the problem is that when you look at this example you immediately
jump to conclusion and think of big companies where every employee have to
belong somewhere (I agree the name of the sample is wrong as it leads to such
conclusion). Lots of small to middle sized companies do not necessarily put
each employee into the department, or one employee can belong to multiple
departments, working part time for each, etc. For this I would be fine to
extend the example so from each employee dialog you can assign them to 1..n
departments, but I still don't think the example would be better by moving
employees into deeper hierarchy.
Another, IMHO important aspect is to show that you don't need to match exactly
company structure, you need to flow with the data. If I'm interested in the
employees, I want to be able to browse them through w/o having to go through
many levels of hierarchy. I only need to be able to find out how they relate to
company hierarchy. ... you see this kind of think every day when trying to
browse image or music collections ... the categorization is nice to have things
organized, but is pain to work with when all you want to is browse. For this
reason the tagging is becoming so popular as it doesn't force the hierarchy.
Similarly I would prefer to "tag" (link) employee w/ the department, rather
then to have them in the hierarchy.
And last aspect of this is resilience of the structure. Companies reorganize
their departments regularly and move employees between them. Having employees
softly linked to their departments makes this more manageable (One can create
new departments and assign employees to them while the old structure is still
in place and searchable, and migrate step by step, rather then changing
everything in one big bang op).
But then again, this is all matter of personal opinion. If you feel that it is
difficult to explain to customers, please come up with the structure and
elements for the example that would show both (hierarchical and flat) part of
the storage and can be used to explain the differences and we can re-work the
sample, let's just try to not make it overly complicated (i.e. if departments
are confusing, let's drop them all together, or if we keep them, let's drop the
permanent/temporary distinction so we keep it light).
> Samples for hierarchical data types have incorrect hierarchy
> ------------------------------------------------------------
>
> Key: MGNLDATA-88
> URL: http://jira.magnolia-cms.com/browse/MGNLDATA-88
> Project: Magnolia Data Module
> Issue Type: Bug
> Environment: Magnolia 4.2 RC 2
> Reporter: Boris Kraft
> Assignee: Philipp Bärfuss
>
> The samples for the hierarchy ("Big-Flower-Inc") seem to have the wrong
> hierarchy.
> The defined hierarchy is as follows:
> Company
> * Employees
> ** Developer
> ** Director
> ** Manager
> * Department
> As you can see, this doesn't allow to create employees within a department.
> It would make more sense to have the following hierarchy:
> Company
> * Department
> ** Employees
> *** Developer
> *** Director
> *** Manager
> The sample content should also reflect this different structure.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
