5 Replies Latest reply on Aug 21, 2009 10:48 AM by sonrosado

    Advanced Spark Menu custom component best practice


      I am looking for the best way to create a Flex (Spark) advances Menu custom component with Flex 4 for a consumer products Website.


      Does anyone know which should be the best approach?


      I want to use only Spark building blocks, and I want the component to be future proof (that is, I don't want to change my code drastically once Flex 4 comes out).


      I've been looking into DataGroup, List, DropDownList, but I don't know yet on which existing components to base my custom component.


      I need to be able to skin my component completely, and the Menu should have transitions and effects.


      The menu will  have submenus.


      The data for the menu/submenu items will conform a hierarchy (this is another question, which collection should I use for the hierarchical data).


      Last, but not least, is it advisable to use mx/Halo components as building blocks, or is it better to leave them out of the equation.



        • 1. Re: Advanced Spark Menu custom component best practice
          David_F57 Level 5

          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.




          1 person found this helpful
          • 2. Re: Advanced Spark Menu custom component best practice
            rfrishbe Level 3

            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.



            • 3. Re: Advanced Spark Menu custom component best practice
              sonrosado Level 1

              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!



              • 4. Re: Advanced Spark Menu custom component best practice
                rfrishbe Level 3

                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.

                1 person found this helpful
                • 5. Re: Advanced Spark Menu custom component best practice
                  sonrosado Level 1

                  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).