Interesting. I never considered that. Although there’s then no way to override in MXML.
I think keeping it a bead leaves the most flexibility. I don’t know of any pain points in Flex. > On Jan 17, 2019, at 11:47 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > IIRC, it doesn't have to be a bead to be specified in CSS. You just have to > define the property. Then ValuesManager will return the Class and you > instantiate. Where you store it after that doesn't matter. It doesn't have > to be a strand. > > It really comes down to how folks should want to work with Formatters. Were > there any pain points in Flex? > > HTH, > -Alex > > On 1/17/19, 1:40 PM, "Harbs" <harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>> wrote: > > OK, true. > > To me the main advantage of it being a bead is the ability to specify the > default in CSS. The idea behind specifying the bead was to specifically > reference it (or override it). Using the bead specified in CSS is difficult > if not impossible in MXML. > >> On Jan 17, 2019, at 10:50 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> Not sure I see any advantage of it being a bead there. What reference to >> the strand or application does it need? Once you give anything an id it is >> "globally" available. >> >> <fx:Declarations> >> <foo:FooFormatter id=“fooFormat”/> >> </fx:Declarations> >> >> <foo:FooComponent> >> <foo:BazComponent text=“{fooFormat.format(date)}”/> >> </foo:FooComponent> >> <foo:SomeOtherFooComponent> >> <foo:SomeOtherBazComponent text=“{fooFormat.format(date)}”/> >> </foo:SomeOtherFooComponent> >> >> My 2 cents, >> -Alex >> >> On 1/17/19, 12:09 PM, "Harbs" <harbs.li...@gmail.com> wrote: >> >> I’d keep it a bead, so you could do something like this (I think): >> <foo:FooComponent> >> <js:beads> >> <foo:FooFormatter id=“fooFormat”/> >> </js:beads> >> <foo:BazComponent text=“{fooFormat.format(date)}”/> >> </foo:FooComponent> >> >>> On Jan 17, 2019, at 9:43 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: >>> >>> >>> >>> On 1/17/19, 11:30 AM, "Harbs" <harbs.li...@gmail.com >>> <mailto:harbs.li...@gmail.com>> wrote: >>> >>> 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. >>> >>> Yeah, I think it is reasonable too. However, calling "new >>> FooFormatter.format(baz)" is not going to work well with >>> Formatters-as-beads. And instantiating a formatter each time is probably >>> also going to be painful for Garbage Collection and if the formatter needs >>> to have other properties set (potentially from locale information). >>> >>> That's why I recommend thinking this through. We need to agree on how >>> folks will want to use and maybe share formatters and how to do so from >>> MXML, which is more property-oriented than function-oriented. >>> >>> One issue is that DateField wants to instantiate its own DateFormatter but >>> then that can't be easily shared as the DateFormatter in a user's app. >>> >>> HTH, >>> -Alex >>> >>>> On Jan 17, 2019, at 9:10 PM, Alex Harui <aha...@adobe.com.INVALID> 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" <cottag...@gmail.com >>>> <mailto:cottag...@gmail.com> <mailto:cottag...@gmail.com >>>> <mailto:cottag...@gmail.com>>> 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 <harbs.li...@gmail.com >>>> <mailto:harbs.li...@gmail.com>> 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%7Cbced50dc7f6141201cb708d67cc46463%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833580332356142&sdata=b6cCyVsAzDTgIhm0BWCrz7CbRf1EAnqTDvz20THxmnw%3D&reserved=0 >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cbced50dc7f6141201cb708d67cc46463%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833580332356142&sdata=b6cCyVsAzDTgIhm0BWCrz7CbRf1EAnqTDvz20THxmnw%3D&reserved=0> >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cbced50dc7f6141201cb708d67cc46463%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833580332356142&sdata=b6cCyVsAzDTgIhm0BWCrz7CbRf1EAnqTDvz20THxmnw%3D&reserved=0 >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cbced50dc7f6141201cb708d67cc46463%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833580332356142&sdata=b6cCyVsAzDTgIhm0BWCrz7CbRf1EAnqTDvz20THxmnw%3D&reserved=0>> >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cbced50dc7f6141201cb708d67cc46463%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833580332356142&sdata=b6cCyVsAzDTgIhm0BWCrz7CbRf1EAnqTDvz20THxmnw%3D&reserved=0 >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cbced50dc7f6141201cb708d67cc46463%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833580332356142&sdata=b6cCyVsAzDTgIhm0BWCrz7CbRf1EAnqTDvz20THxmnw%3D&reserved=0> >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cbced50dc7f6141201cb708d67cc46463%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833580332356142&sdata=b6cCyVsAzDTgIhm0BWCrz7CbRf1EAnqTDvz20THxmnw%3D&reserved=0 >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cbced50dc7f6141201cb708d67cc46463%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833580332356142&sdata=b6cCyVsAzDTgIhm0BWCrz7CbRf1EAnqTDvz20THxmnw%3D&reserved=0>>>
