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