Missing Spark Components : ProgressBar
On the same Github repository , I have added a skinnable ProgressBar component. Enjoy, and if you have feedback, feature requirements or bugs, feel free to comment here or write me an email.
On the same Github repository , I have added a skinnable ProgressBar component. Enjoy, and if you have feedback, feature requirements or bugs, feel free to comment here or write me an email.
You can find the following missing Spark components, developed by me on Github :
1. Alert (org.apache.flex.spark.components.alert.Alert)
2. ColorPicker (org.apache.flex.spark.components.colorpicker.ColorPicker)
3. HDividerGroup (org.apache.flex.spark.components.dividers.HDividerGroup)
4. VDividerGroup (org.apache.flex.spark.components.dividers.VDividerGroup)
5. Menu and MenuBar (org.apache.flex.spark.components.menu.Menu and org.apache.flex.spark.components.menu.MenuBar).
Enjoy!
Feel free to contact me if you have questions or find bugs.
Here are some benefits I think will immediately appear :
1. Life-cycle of the components will be much easier to understand and eventually tweak upon needs. By separating concerns in behavior classes, anyone will be able to understand the logic behind it and extend that class rather than altering the life-cycle in some undesired way.
2. The new Apache SDK will maintain compatibility with existing SDKs, allowing existing developers to use the SDK the way they learned it, gradually migrating to this new way. All those existing tutorials will be still valid for the new SDK, until the community will create new ones to document how to make use of the behavior classes.
3. All UIComponents extenders will become lightweight : I’m just thinking that now, a spark component is fast, but could be even faster by “dismounting” unwanted behavior from ‘hostComponent’ and mounting it to the skin.
4. Directly from the above, we will benefit of a smaller memory foot print and a lightweight job for SDK’s managers. I’m thinking, being able to control what the SDK’s managers are handling, just by removing unwanted behavior classes from our components.
5. Having specialized behavior classes, we will be able to reuse code much efficiently, without the danger of having a premature optimization case.
6. Will provide a very powerful way of including other frameworks directly into SDK (thinking about beloved Spring or RobotLegs) just by overriding behavior classes to have injections.
7. Will provide an easier way to write inspector classes and/or custom automation (I will not get into details).
8. Flex will become even more flexible, allowing advanced developers to do magic things just by adding or altering behavior classes.