I don’t think you could use interfaces in that case.
Also, some formatters have options such as separator and such. I guess the
options could be static, but that would preclude having more than one setting
in a single app.
> On Jan 18, 2019, at 11:33 AM, Carlos Rovira <carlosrov...@apache.org> wrote:
>
> Hi,
> just one thing to add to the discussion. Maybe could be good to implement
> as static so we don't need an instance per component?
> So using "SomeFormatterClass.format(date)" could be possible?
>
> El vie., 18 ene. 2019 a las 4:38, Alex Harui (<aha...@adobe.com.invalid>)
> escribió:
>
>> You can override in MXML if the code checks before loading from
>> ValuesManager.
>>
>> What strands can it go on and why?
>>
>> -Alex
>>
>> On 1/17/19, 2:16 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>> 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%7Cf94019751d934c60bb2d08d67cc9643e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833601775326776&sdata=2F%2BRWlR1o%2Bh7piIABUOwKWRaL4VhuFWYYwgHrkq994c%3D&reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cf94019751d934c60bb2d08d67cc9643e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833601775326776&sdata=2F%2BRWlR1o%2Bh7piIABUOwKWRaL4VhuFWYYwgHrkq994c%3D&reserved=0>
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cf94019751d934c60bb2d08d67cc9643e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833601775326776&sdata=2F%2BRWlR1o%2Bh7piIABUOwKWRaL4VhuFWYYwgHrkq994c%3D&reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cf94019751d934c60bb2d08d67cc9643e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833601775326776&sdata=2F%2BRWlR1o%2Bh7piIABUOwKWRaL4VhuFWYYwgHrkq994c%3D&reserved=0>>
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cf94019751d934c60bb2d08d67cc9643e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833601775326776&sdata=2F%2BRWlR1o%2Bh7piIABUOwKWRaL4VhuFWYYwgHrkq994c%3D&reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cf94019751d934c60bb2d08d67cc9643e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833601775326776&sdata=2F%2BRWlR1o%2Bh7piIABUOwKWRaL4VhuFWYYwgHrkq994c%3D&reserved=0>
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cf94019751d934c60bb2d08d67cc9643e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833601775326776&sdata=2F%2BRWlR1o%2Bh7piIABUOwKWRaL4VhuFWYYwgHrkq994c%3D&reserved=0
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cf94019751d934c60bb2d08d67cc9643e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833601775326776&sdata=2F%2BRWlR1o%2Bh7piIABUOwKWRaL4VhuFWYYwgHrkq994c%3D&reserved=0
>>>>>
>>
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
