You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2019/01/17 16:26:20 UTC
Formatter Classes
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
Re: Formatter Classes
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
For me is ok.
I think we had an issue with Formatters in Jewel DateField (that seems
could be solved with your point 4.) when using in a different locale. We
use it for Spanish therefore we use DateFormatDDMMYYYY
(Our config for the records in app is:
j|DateField
IFormatBead: ClassReference(
"org.apache.royale.html.accessories.DateFormatDDMMYYYY")
IDateControlConfigBead: ClassReference(
"org.apache.royale.jewel.beads.controls.datefield.SpanishDateComponentConfig"
)
)
But when the user enters a date the date is MMDDYYYY and we need to change
it programmatically to DDMMYYYY
(For that we have a temporaly patched Jewel DateFieldMouseController that
makes this)
I think that should be part of the formatter right?
but the formatter is only this code:
public class DateFormatDDMMYYYY extends SimpleDateFormatter
{
/**
* constructor.
*
* @langversion 3.0
* @playerversion Flash 10.2
* @playerversion AIR 2.6
* @productversion Royale 0.8
*/
public function DateFormatDDMMYYYY()
{
format = "DD/MM/YYYY";
}
}
So If you plan to make this change I think it would be good to address this
issue, since right now we're relying in a hack (the patched
DateFieldMouseController), and if Dateformatter has format that handles a
Date, that should fix this. And we should be able to remove our version of
the jewel DateFieldMouseController
thanks
Carlos
El jue., 17 ene. 2019 a las 18:36, Andrew Wetmore (<co...@gmail.com>)
escribió:
> 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 <ha...@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
>
> http://cottage14.blogspot.com/
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Formatter Classes
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IIRC, functions/methods can be given [Bindable] metadata and avoid warnings.
HTH,
-Alex
On 1/18/19, 9:21 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
I think about warnings when you have property in some object without
[Bindable] tag and you use that property as source of some data in mxml.
public var myProperty:Stringi;
<Component text={myProperty}/>
Thanks,
Piotr
On Fri, Jan 18, 2019, 6:17 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> @Piotr: What warning do you expect? I think it would work.
>
> @Carlos/Harbs: Static is my least favorite pattern for sharing an
> instance. id/global is ok. Singleton is better, IMO. Locators are too
> heavy. Purists don't like sharing outside of passed-in context, but I'm
> not a purist.
>
> My 2 cents,
> -Alex
>
> On 1/18/19, 6:07 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>
> Hi Guys,
>
> Going in that way:
>
> <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>
>
>
> We probably have Bindable warning - Am I right?
>
> Thanks,
> Piotr
>
> On Fri, Jan 18, 2019, 2:37 PM Harbs <ha...@gmail.com> wrote:
>
> > 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 <
> carlosrovira@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
> (<aharui@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" <ha...@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
> <ah...@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.lists@gmail.com <mailto:
> > >> harbs.lists@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
> <ah...@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" <ha...@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
> <ah...@adobe.com.INVALID>
> > >> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> > >> harbs.lists@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
> <ah...@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" <cottage14@gmail.com
> > >> <ma...@gmail.com> <mailto:cottage14@gmail.com <mailto:
> > >> cottage14@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.lists@gmail.com
> > >> <ma...@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%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=lix5X4oetCLJjBEsLY7zKxK3Or1ZuiW4v8Uip83Hboo%3D&reserved=0
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=lix5X4oetCLJjBEsLY7zKxK3Or1ZuiW4v8Uip83Hboo%3D&reserved=0
> > >
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=lix5X4oetCLJjBEsLY7zKxK3Or1ZuiW4v8Uip83Hboo%3D&reserved=0
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=lix5X4oetCLJjBEsLY7zKxK3Or1ZuiW4v8Uip83Hboo%3D&reserved=0
> > >>
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=lix5X4oetCLJjBEsLY7zKxK3Or1ZuiW4v8Uip83Hboo%3D&reserved=0
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=lix5X4oetCLJjBEsLY7zKxK3Or1ZuiW4v8Uip83Hboo%3D&reserved=0
> > >
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=lix5X4oetCLJjBEsLY7zKxK3Or1ZuiW4v8Uip83Hboo%3D&reserved=0
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=lix5X4oetCLJjBEsLY7zKxK3Or1ZuiW4v8Uip83Hboo%3D&reserved=0
> > >>>>>
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cba226772eee94dcfe3b308d67d6952f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834288647476375&sdata=fDZd51URvjBIQSDQSQaYQs3dm6uNy9cW5zYq4l6R%2Fao%3D&reserved=0
> >
> >
>
>
>
Re: Formatter Classes
Posted by Piotr Zarzycki <pi...@gmail.com>.
I think about warnings when you have property in some object without
[Bindable] tag and you use that property as source of some data in mxml.
public var myProperty:Stringi;
<Component text={myProperty}/>
Thanks,
Piotr
On Fri, Jan 18, 2019, 6:17 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> @Piotr: What warning do you expect? I think it would work.
>
> @Carlos/Harbs: Static is my least favorite pattern for sharing an
> instance. id/global is ok. Singleton is better, IMO. Locators are too
> heavy. Purists don't like sharing outside of passed-in context, but I'm
> not a purist.
>
> My 2 cents,
> -Alex
>
> On 1/18/19, 6:07 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>
> Hi Guys,
>
> Going in that way:
>
> <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>
>
>
> We probably have Bindable warning - Am I right?
>
> Thanks,
> Piotr
>
> On Fri, Jan 18, 2019, 2:37 PM Harbs <ha...@gmail.com> wrote:
>
> > 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 <
> carlosrovira@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
> (<aharui@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" <ha...@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
> <ah...@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.lists@gmail.com <mailto:
> > >> harbs.lists@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
> <ah...@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" <ha...@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
> <ah...@adobe.com.INVALID>
> > >> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> > >> harbs.lists@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
> <ah...@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" <cottage14@gmail.com
> > >> <ma...@gmail.com> <mailto:cottage14@gmail.com <mailto:
> > >> cottage14@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.lists@gmail.com
> > >> <ma...@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%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> > >
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> > >>
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> > >
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716697449&sdata=m4oaC%2Bzbftwu851Z6Xc4igX8sc3QwlemoOMgt2S2c6Q%3D&reserved=0
> > >> <
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716697449&sdata=m4oaC%2Bzbftwu851Z6Xc4igX8sc3QwlemoOMgt2S2c6Q%3D&reserved=0
> > >>>>>
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716697449&sdata=3jzfuqWdMdKoDpOg8ll9L%2FX0Za4MXVB15bwLsLmW20c%3D&reserved=0
> >
> >
>
>
>
Re: Formatter Classes
Posted by Alex Harui <ah...@adobe.com.INVALID>.
@Piotr: What warning do you expect? I think it would work.
@Carlos/Harbs: Static is my least favorite pattern for sharing an instance. id/global is ok. Singleton is better, IMO. Locators are too heavy. Purists don't like sharing outside of passed-in context, but I'm not a purist.
My 2 cents,
-Alex
On 1/18/19, 6:07 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
Hi Guys,
Going in that way:
<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>
We probably have Bindable warning - Am I right?
Thanks,
Piotr
On Fri, Jan 18, 2019, 2:37 PM Harbs <ha...@gmail.com> wrote:
> 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 <ca...@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 (<aharui@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" <ha...@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 <ah...@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.lists@gmail.com <mailto:
> >> harbs.lists@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
> >> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> >> harbs.lists@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 <ah...@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" <cottage14@gmail.com
> >> <ma...@gmail.com> <mailto:cottage14@gmail.com <mailto:
> >> cottage14@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.lists@gmail.com
> >> <ma...@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%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> >
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> >>
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716687440&sdata=84eY3tr2cwMZTv37Gw2OVzyDcgIa1QLLv5D6xFrRb2Q%3D&reserved=0
> >
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716697449&sdata=m4oaC%2Bzbftwu851Z6Xc4igX8sc3QwlemoOMgt2S2c6Q%3D&reserved=0
> >> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716697449&sdata=m4oaC%2Bzbftwu851Z6Xc4igX8sc3QwlemoOMgt2S2c6Q%3D&reserved=0
> >>>>>
> >>
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C700b981c76f64b33c0af08d67d4e5253%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636834172716697449&sdata=3jzfuqWdMdKoDpOg8ll9L%2FX0Za4MXVB15bwLsLmW20c%3D&reserved=0
>
>
Re: Formatter Classes
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Guys,
Going in that way:
<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>
We probably have Bindable warning - Am I right?
Thanks,
Piotr
On Fri, Jan 18, 2019, 2:37 PM Harbs <ha...@gmail.com> wrote:
> 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 <ca...@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 (<aharui@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" <ha...@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 <ah...@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.lists@gmail.com <mailto:
> >> harbs.lists@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
> >> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> >> harbs.lists@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 <ah...@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" <cottage14@gmail.com
> >> <ma...@gmail.com> <mailto:cottage14@gmail.com <mailto:
> >> cottage14@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.lists@gmail.com
> >> <ma...@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
>
>
Re: Formatter Classes
Posted by Harbs <ha...@gmail.com>.
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 <ca...@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 (<ah...@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" <ha...@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 <ah...@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.lists@gmail.com <mailto:
>> harbs.lists@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <mailto:
>> harbs.lists@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 <ah...@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" <cottage14@gmail.com
>> <ma...@gmail.com> <mailto:cottage14@gmail.com <mailto:
>> cottage14@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.lists@gmail.com
>> <ma...@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
Re: Formatter Classes
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ah...@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" <ha...@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 <ah...@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.lists@gmail.com <mailto:
> harbs.lists@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
> wrote:
> >>>
> >>>
> >>>
> >>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@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 <ah...@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" <cottage14@gmail.com
> <ma...@gmail.com> <mailto:cottage14@gmail.com <mailto:
> cottage14@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.lists@gmail.com
> <ma...@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
Re: Formatter Classes
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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.lists@gmail.com <ma...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID> wrote:
>>>
>>>
>>>
>>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <ma...@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 <ah...@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" <cottage14@gmail.com <ma...@gmail.com> <mailto:cottage14@gmail.com <ma...@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.lists@gmail.com <ma...@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>>>
Re: Formatter Classes
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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.lists@gmail.com <ma...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID> wrote:
>>>
>>>
>>>
>>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <ma...@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 <ah...@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" <cottage14@gmail.com <ma...@gmail.com> <mailto:cottage14@gmail.com <ma...@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.lists@gmail.com <ma...@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>>>
Re: Formatter Classes
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID> wrote:
>>
>>
>>
>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <ma...@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 <ah...@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" <cottage14@gmail.com <ma...@gmail.com> <mailto:cottage14@gmail.com <ma...@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.lists@gmail.com <ma...@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>>
>
>
>
Re: Formatter Classes
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID> wrote:
>>
>>
>>
>> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <ma...@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 <ah...@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" <cottage14@gmail.com <ma...@gmail.com> <mailto:cottage14@gmail.com <ma...@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.lists@gmail.com <ma...@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>>
>
>
>
Re: Formatter Classes
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <ma...@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 <ah...@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" <cottage14@gmail.com <ma...@gmail.com> <mailto:cottage14@gmail.com <ma...@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.lists@gmail.com <ma...@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>>
Re: Formatter Classes
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 1/17/19, 11:30 AM, "Harbs" <harbs.lists@gmail.com <ma...@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 <ah...@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" <cottage14@gmail.com <ma...@gmail.com> <mailto:cottage14@gmail.com <ma...@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.lists@gmail.com <ma...@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>>
Re: Formatter Classes
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 1/17/19, 11:30 AM, "Harbs" <ha...@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 <ah...@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" <cottage14@gmail.com <ma...@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 <ha...@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>
Re: Formatter Classes
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <cottage14@gmail.com <ma...@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 <ha...@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%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>
Re: Formatter Classes
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <co...@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 <ha...@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%7C82d39a100fd0429e80d908d67ca23fad%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636833433629411677&sdata=%2FByWx8FrI%2FkuoTVHCZO5bIqC40lvZdspn5nhZNgrcoY%3D&reserved=0
Re: Formatter Classes
Posted by Andrew Wetmore <co...@gmail.com>.
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 <ha...@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
http://cottage14.blogspot.com/