I have the occasion this week to deal with the formatter classes, and I’d like to make some changes. I’d like input from others on the subject.
Taking SimpleDateFormatter as an example: 1. The Formatter assumes that its being attached to a Strand with an IDateChooserModel. 2. It requires a “propertyName to be set and concatenates that with “Changed” and adds an event listener to the model. 3. When the property is changed, it formats the result which must be a “selectedDate” and then dispatches an event. 4. The view bead must attach an event listener to the Formatter to get notification when the format changes. 5. It also invariably attaches an event listener to the model when the model changes. 6. When the model changes we have first an event picked up by the formatter and then the formatter dispatches a separate event which is picked up by the view. The view then explicitly gets the formatted date from the formatter. That’s a lot of indirection for no apparent reason. It also limits how a formatter can be used. A DateFormatter can only be used in conjunction with a IDateChooserModel and it can only format a “selectedDate”. I ran into issues when trying to figure out how to use the formatters with date ranges. I want to change it to the following: 1. Make the formatter classes very simple Beads. 2. It will make no assumptions on there being any other beads and will not attach any event listeners. 3. Likewise, it will not dispatch any events. 4. Date Formatter classes would have a format(date:Date):String method which would take any valid date and return the formatted string. 5. When a view needs to update a formatted date, it would simply get the format bead and call format(). This would allow the bead to be instantiated by any class and would greatly simplify the code. I’d make similar changes to the other formatter classes. Any objections to these changes? Harbs
