Currently, the view must know about the formatter AND the formatter must know about the view.
I’m proposing that the view knows there is an IFormatter and just calls a format() function which is common to all formatters. Changing it to the way I’m proposing would also allow for something like this: text = new FooFormatter.format(baz); I think it’s reasonable for a view to know it’s using some formatter. > On Jan 17, 2019, at 9:10 PM, Alex Harui <[email protected]> wrote: > > I don't like the way it is now. That sounds more like a validator workflow. > Having DateFormatter require IDateChooserModel doesn't sound right. I think > the goal of the current implementation was to not require the views to know > about the formatter. Then you could change what the view would display by > using a different formatting bead. Maybe that was a bad idea. I think you > are proposing that the views know they are using a formatter. > > Let's think about how we want Formatters to be used. The first question that > comes to mind is whether the common case is that a single formatting > "algorithm" would be used throughout an application. If so, then scattering > formatting beads on strands in different places in the application will be > painful to manage unless you have a central config to manage them. > > IOW, I think it would be rare for dates or currency to be formatted in one > way in some component and differently in some other component. > > The second thing to consider is loose-coupling. How will the View find a > formatter? The advantage of beads is that formatters can be replaced, but > only if the view finds the formatter by interface name. But then they might > be able to find the formatter some other way anyway. Related: should the > presence of a formatter be optional? I think not in the common case. The > view shouldn't have to worry about the formatter not being there when > expected. A view either needs a formatter or it doesn’t. > > Next question: How should views be able to use formatters when written in > MXML? If there is a shared formatter, that implies function call binding > which is sort of heavy. Having a bead for each property being formatted > allows the binding system to use SimpleBinding which is cheaper/faster. But > I think it might be too painful to have a formatter instance for each > formatted property. > > So, maybe it is better to have Views expect formatters. But maybe formatters > should be Singletons so they are shared. > > Thoughts? > -Alex > > On 1/17/19, 9:36 AM, "Andrew Wetmore" <[email protected] > <mailto:[email protected]>> wrote: > > This simplification sounds good. Will you be annotating how to use the new > bead structures, maybe with some examples, for those of us who are lost > among the strands? > > On Thu, Jan 17, 2019 at 12:26 PM Harbs <[email protected]> wrote: > >> 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 > > > > -- > Andrew Wetmore > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C82d39a100fd0429e80d908d67ca23fad%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833433629411677&sdata=%2FByWx8FrI%2FkuoTVHCZO5bIqC40lvZdspn5nhZNgrcoY%3D&reserved=0 > > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C82d39a100fd0429e80d908d67ca23fad%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833433629411677&sdata=%2FByWx8FrI%2FkuoTVHCZO5bIqC40lvZdspn5nhZNgrcoY%3D&reserved=0>
