The good bad reason is named heritage.
FTFY.
I have not once since 2007 ('06?) run into a situation where I myself, or any of my employers or clients, have thought "oh Gosh, this restriction on the second level in the package hierarchy is really useful. Wow. What a selling point."
I have, on the other hand, run into any number of situations where I've wanted to move a package to or from this magical second level but have been unable to. It also trips up new users, raising the adoption threshold just that little bit.
I can accept that the top level warrants some (some!) special handling. OK fine. But one step down it makes no sense whatsoever. As qwerty says, there are historical reasons, but EA has long since passed the point where it made sense for Sparx to supply any suggestions for structuring your project -- usage is simply too varied.
I might also add as a side note that there is (in 11.1) no corresponding error message when trying to drag a non-view package into a root node. It just fails silently.
Now the good thing is that it shouldn't be that hard to fix. Views are not a separate class in the API, nor are they stored in a special table in the database. They're simply packages, and as such are stored in
t_object and
t_package, with the fact that they're views stored in
t_package.PackageFlags along with the view icon ("isModel=1;VICON=2;").
The flags can be set in the API, and some hacking proves that they're ignored when they don't make sense. So if you set the flags as for a view on a non-view package, that doesn't affect how it is displayed in the project browser, nor does it allow you to move it to the view level of the hierarchy. Similarly, removing the flags for a view only causes it to be displayed with the default icon ("simple"), it doesn't allow you to move it into another package.
So there's some special handling going on in the project browser which checks the actual location of a package before deciding whether to display a view-style icon, and before deciding whether to allow the package to be moved to/from the view level.
Which means it should be easy enough to track down and fix. In order to minimize impact, I suggest the following:
- Dragging a view into a package: remove isModel flag, keep VICON flag.
- Dragging a non-view package into a root node: add isModel flag, retain old VICON flag if one exists, otherwise set VICON=1.
How's that sound?
/Uffe
