Why does EA enforce a root node to have a second level of "views"?

[YogaMatt]

Does anybody know ...

Why does EA enforce a root node to have a second level of "views" before you can add a package to the third level?
Or, put another way, why can't packages be placed directly under nodes? What's the essential difference between packages and views in the browser?

Thanks in advance.

[PeterHeintz]

This is a question that I asked myself as well and it means form e I have to do some things I just do to satisfy EA. I assume the more historical than really needed.

[qwerty]

This is pure legacy. It has been discussed here to give that up (and it would probably be easy), but Sparx is very conservative when it comes to such kind of useless stuff.

q.

[Uffe]

What's the essential difference between packages and views in the browser?

I dug through this a while back. Here's what I came up with. Use this information at your own risk.

A regular package is represented by both a t_package row and a t_object row. They appear to have the same ea_guid, but Sparxians have warned us before that that is subject to change without notice. However, the t_object.PDATA1 column will match t_package.Package_ID.

A View package has the same representation in the database, except there is additional information in t_package.PackageFlags, namely isModel=1;VICON=n;, where n is 0-5, specifying the view icon shown in the project browser.

A Root Node is a little different still. It only has a t_package row, not a corresponding t_object one. Its t_package.PackageFlags is set to isModel=1;, but it has no view icon. t_package.Parent_ID is 0.

EA prevents you from moving root nodes and views to other levels in the package hierarchy, and from moving a regular package to the root or view levels. You can work around this using the API (by setting Package.ParentID), but only for moving between the view and package levels, not to/from the root level.

This explains why views, but not root nodes, behave as regular packages in that they can be shown in diagrams and be the source or target of connectors: it's because root nodes are not t_objects, just t_packages, and only t_objects can be can be used that way in the EA data model.

Hope this confuses you further helps,


/Uffe

[qwerty]

Basically because of and as a result of the previously stated effects, EA treats roots and view differently in the code. Still, it would not be difficult to unify this via stereotypes. But Sparx IS conservative. Rumors have it, they made the model for conserving the mummies of the Pharaos. - Just kidding. Their boss is actually a re-incarnation of a mummy 

q.

[Glassboy]

Basically because of and as a result of the previously stated effects, EA treats roots and view differently in the code. Still, it would not be difficult to unify this via stereotypes. But Sparx IS conservative. Rumors have it, they made the model for conserving the mummies of the Pharaos. - Just kidding. Their boss is actually a re-incarnation of a mummy 

<ob pedantry>The mummy is the part that doesn't get reincarnated.</pedantry>

[qwerty]

I actually meant that movie, you know? Where that mummy comes to live again. Can't recall the title.

q.

[Glassboy]

I actually meant that movie, you know? Where that mummy comes to live again. Can't recall the title.

Throw Momma from the Train.   

[Paolo F Cantoni]

I actually meant that movie, you know? Where that mummy comes to live again. Can't recall the title.

Throw Momma from the Train.   

For the benefit of those NOT from the southern hemisphere, Kiwi's have a weird sense of humour (even by Aussie standards).

Still, it IS Friday!

Paolo

[Glassboy]

For the benefit of those NOT from the southern hemisphere, Kiwi's have a weird sense of humour (even by Aussie standards).

One of the basics of comedy is the unexpected answer.  It does help that help that our official languages are all biased towards the figurative rather than the literal.   

[Uffe]

I actually meant that movie, you know? Where that mummy comes to live again. Can't recall the title.

Throw Momma from the Train.   

Surely that's Throw Momma from the Train II ?

In the first she gets thrown off, in the sequel, to quote Sir Elton, the bitch is back. 

[qwerty]

It's The Mummy Returns.

q.

[Paolo F Cantoni]

[SNIP]
For the benefit of those NOT from the southern hemisphere, Kiwi's have a weird sense of humour (even by Aussie standards).

Sunday, saw the new Kiwi movie:  "The hunt for the wilderpeople".  (Wilderpeople as in Wildebeest)  A fine example of Kiwi humour!  Laugh out loud stuff.

Great movie for a weekend!  Highly recommended!

Paolo

[YogaMatt]

What's the essential difference between packages and views in the browser?

I dug through this a while back. Here's what I came up with. Use this information at your own risk.

A regular package is represented by both a t_package row and a t_object row. They appear to have the same ea_guid, but Sparxians have warned us before that that is subject to change without notice. However, the t_object.PDATA1 column will match t_package.Package_ID.

A View package has the same representation in the database, except there is additional information in t_package.PackageFlags, namely isModel=1;VICON=n;, where n is 0-5, specifying the view icon shown in the project browser.

A Root Node is a little different still. It only has a t_package row, not a corresponding t_object one. Its t_package.PackageFlags is set to isModel=1;, but it has no view icon. t_package.Parent_ID is 0.

EA prevents you from moving root nodes and views to other levels in the package hierarchy, and from moving a regular package to the root or view levels. You can work around this using the API (by setting Package.ParentID), but only for moving between the view and package levels, not to/from the root level.

This explains why views, but not root nodes, behave as regular packages in that they can be shown in diagrams and be the source or target of connectors: it's because root nodes are not t_objects, just t_packages, and only t_objects can be can be used that way in the EA data model.

Hope this confuses you further helps,


/Uffe

I enjoyed everyone else's banter, but thanks to Uffe I have a path to automate project template instantiation.