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%7Ce5434cf1c945490636c008d67cb239fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833502257087373&sdata=oGcMoT%2F46jYfLuy%2FUPsmt6hyCpQyM8p9w5QUy9I9fOo%3D&reserved=0
>>
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ce5434cf1c945490636c008d67cb239fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833502257087373&sdata=oGcMoT%2F46jYfLuy%2FUPsmt6hyCpQyM8p9w5QUy9I9fOo%3D&reserved=0>
>>
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ce5434cf1c945490636c008d67cb239fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833502257087373&sdata=oGcMoT%2F46jYfLuy%2FUPsmt6hyCpQyM8p9w5QUy9I9fOo%3D&reserved=0
>>
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ce5434cf1c945490636c008d67cb239fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833502257087373&sdata=oGcMoT%2F46jYfLuy%2FUPsmt6hyCpQyM8p9w5QUy9I9fOo%3D&reserved=0>>
