1 person found this helpful
Future proof is a big ask in this industry
Obviously the new spark library has a lot going for it in terms of skinning and animations, unfortunately a lot of the components have only a subset of the halo functionality, (group is a pain to use in comparison to canvas). At the end of the day it's what you feel most comfortable with, but with the flexibility that the new components offer I would go as new as possible and only drop back to halo if its a vital necessity.
Menu hierarchy- I still think xml is hard to beat for simplicity and maintainability.
So there are probably a lot of different approaches you could take. One that would be similar to the Halo approach would be creating a data-driven menu that relies on DataGroup to render the menu items. I really haven't thought about it much, but to get started, I'd try creating a Menu class that extends SkinnableComponent (or maybe List or ListBase). In the skin, I would have one required skin part, dataGroup, and I'd put that DataGroup inside of a PopUp control, similar to DropDownLists's skin. From the menu class, you can push the data in to the dataGroup. On that dataGroup you could use an itemRendererFunction, which would use a different itemRenderer depending on whether it's a leaf node or whether it has a submenu.
As you work on this and stumble through issues, you should post your experience on here and post any questions you have.
Thank you Ryan for your answer. I think it hits right on the mark! I will be working on this and posting my progress.
Now, some clarification: when you suggest creating a Menu class that extends SkinnableComponent, do you think I should try to mimic some aspects of the Halo Menu class? Or should I start from scratch, given the differences between frameworks. Thanks!
1 person found this helpful
I'm not really sure what you mean with "mimic some aspects of the Halo Menu class". I think the Halo menu class would be a great start as it's a pretty good reference and has worked in the past. I might copy bits and pieces of the code, but I wouldn't extend Menu or copy a lot of the code verbatim.
The Halo menu is a good starting point in terms of design and APIs, but that said, there are definitely different ways to approach it. For instance, rather than having the component be data-driven (you pass in data, we create item renderers), another approach would be to create MenuItem objects that are SkinnableComponents themselves. Then you just push those as children of the Menu directly. I think that's also a good option, as most of the time you don't really need a menu to be data-driven...we just made it that way for convinience in terms of implementation.
I am still working on this.
Regarding your suggestion, and if I take the first approach, do you think the SparkMenu class should extend DropDownList, List, ListBase or SkinnableDataContainer?
I see different architectural implications with each choice.
PS: I need to use a data provider and I need to use hierarchical data (such as in XML).