Halo Containers with Spark Content
Issue:
Halo Navigators demand that their child views are Halo Containers. Since we don't have Spark navigators, if you want an Accordion or TabNavigator in your app, you will most likely instantiate a Halo navigator. What if you want to put Spark content in as a child view of your navigator? Say a Group, or a Spark Container? Right now, you will get an RTE when you try to select that child view, with a slightly obscure error message indicating the child view is not of the right type.
Description:
There are a couple of things we can do:
1.) Leave as is - if you want to put Spark containers (or containment elements like a Group) in as a child view of a Halo navigator, you must wrap that view in a Halo container. We should beef up the RTE to be more sensible, and perhaps add in a compiler warning to detect for these cases and warn the user.
2.) Relax the restriction on Halo navigators and have them accept children who are IVisualElementContainers (meaning Spark Containers, Halo containers and Groups). This would require the addition of a label property on IVisualElementContainer such that navigators knew what the label of their child views were for display in accordion panes or tabs.
Note - deferred instantiation throws a wrench into things. Halo navigators use deferred instantiation - they create the top-level children of their child views, but none of the subsequent children. Only when that view is navigated to, does the rest of the content get created. In Spark, only Container is DI-aware. Group is not. If we relaxed the restriction on Halo navigators to accept children that are IVisualElementContainers, we now have the case where everything BUT Group is DI-aware, which is an integral part of Halo navigators' behavior.
Resolution:
We opted for solution 1. Partly because down the line we may introduce Spark Accordion and Spark Tab Navigator, so keeping Halo's restriction would be ok (since we could design the Spark navigators however we so desired). Additionally, there's no way to create a Spark Container or Group instance as the child view of a Navigator in Flex Builder, unless you hand-code it. The UI in Design View always prompts you for the Halo container that will act as the housing container for your navigator child view content. And finally, we didn't want to muddy Group by adding in deferred instantiation, but relaxing navigators to have some DI-aware content and not was weird.
So, we'll be keeping the restriction on Halo navigators that child views must be Halo containers. Additionally, we will clean up the runtime RTE such that it makes more sense and is clear to whomever may encounter it with what went wrong. AND, we'll add a compiler error that detects child views of Halo navigators that are not Halo containers in markup.
| You must be logged in to comment. |
|
I believe the implementation of Solution 1 in Beta 1 is overly Draconian: It's preventing non-visual classes that implement IMXMLObject from being present in Halo containers. I think I understand the intent of the restriction, but I think non-visuals should be exempted from it.