Unable to change DateChooser controller without errors

[justinmclean]

Currently you can't change DateChooser controller class in MXML but assuming you could and did this then the Mouse controller gets replaced buy the keyboard controller. This seems to be by design - is this correct?

                <js:DateChooser id="chooser" width="300" click="displayDate()">
                    <js:beads>
                        <js:DateChooserKeyboardController />
                    </js:beads>
                </js:DateChooser>

So to fix it you add both controllers.

                <js:DateChooser id="chooser" width="300" click="displayDate()">
                    <js:beads>
                        <js:DateChooserMouseController />
                        <js:DateChooserKeyboardController />
                    </js:beads>
                </js:DateChooser>

This will die with a RTE in in DateChooserMouseController set strand method as getBeadByType fails to find the view (it's not in the list of beads yet) and returns null.

        var view:DateChooserView = value.getBeadByType(IBeadView) as DateChooserView;
	view.prevMonthButton.addEventListener("click", prevMonthClickHandler);
	view.nextMonthButton.addEventListener("click", nextMonthClickHandler);

Perhaps the view could be obtained from value.view which does have the correct value?

This fixes it but seem rather verbose:

                <js:DateChooser id="chooser" width="300" click="displayDate()">
                    <js:view>
                        <beads:DateChooserView />
                    </js:view>
                    <js:beads>
                        <js:DateChooserMouseController />
                        <js:DateChooserKeyboardController />
                    </js:beads>
                </js:DateChooser>

Is it more correct / in line with PAYG to fix the issue in the DateChooserMouseController set strand method? Or should the default view be added to the beads before the set strand method is called?

[Harbs]

Controllers can be specified in CSS files.

There is only one controller, but there's no reason a controller cannot be comprised of beads.

If you want to specify the controller in MXML, you can probably do so if you also specify the view. The view must be first.

The reason it failed was because MXML is evaluated before CSS-specified components are added.

[justinmclean]

I could make a DateChooserMouseKeyboardController that has both beads but seem a little unnecessary as the above code with two controller beads and the view does work (once the controllers are added to the manifest file).

Where in the code does it limit it to only one controller?

[Harbs]

Controllers are specialized beads. As are View and Model beads. Each component is supposed to have only one of each interface type. The same goes for other specialized beads such as Layouts, Viewports, etc. This enables specifying the bead types via CSS.

When the order of the beads is important (such as with Controller and View beads) and the beads are specified via CSS, the beads are added in the correct order. If they are specified using MXML, the order must be correct.

I've started work on restructuring strands and beads so the architecture is a bit more predictable and forgiving, but I have not yet finished that and it's still in a feature branch.

[justinmclean]

OK I've combined both beads into a single bead than can be used in CSS or like so:

                <js:DateChooser>
                    <js:view>
                        <beads:DateChooserView />
                    </js:view>
                    <js:beads>
                        <js:DateChooserMouseKeyboardController />
                    </js:beads>
                </js:DateChooser>

The view still has be specified otherwise the Mouse controller throws an RTE (DateChooserMouseController.js:97 Uncaught TypeError: Cannot read property 'prevMonthButton' of null)

[justinmclean]

I note that this has been closed but the associated pull request [1] not merged why is that?

1. Date chooser keyboard controlled to select dates with cursor keys #29

[Harbs]

It was closed because you resolved your issue.

I have not merged your pull request because I have not had the time to review it. If you want to make it easier to review and merge, you can resolve the conflicts with the develop branch. There's no way to merge the pull request as-is.

[justinmclean]

How is the issue resolved if the pull request not dealt with? For example if someone wanted to use the above code they would need to check out a branch of my fork of Royale on GitHub.

There were no conflicts when the pull request was first made (over 3 weeks ago) but I'll look into what they are and fix.