@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" <piotrzarzyck...@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 <harbs.li...@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 <carlosrov...@apache.org>
> wrote:
> >
> > Hi,
> > just one thing to add to the discussion. Maybe could be good to
implement
> > as static so we don't need an instance per component?
> > So using "SomeFormatterClass.format(date)" could be possible?
> >
> > El vie., 18 ene. 2019 a las 4:38, Alex Harui (<aha...@adobe.com.invalid
> >)
> > escribió:
> >
> >> You can override in MXML if the code checks before loading from
> >> ValuesManager.
> >>
> >> What strands can it go on and why?
> >>
> >> -Alex
> >>
> >> On 1/17/19, 2:16 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>
> >> Interesting. I never considered that. Although there’s then no way
to
> >> override in MXML.
> >>
> >>
> >> I think keeping it a bead leaves the most flexibility.
> >>
> >> I don’t know of any pain points in Flex.
> >>
> >>> On Jan 17, 2019, at 11:47 PM, Alex Harui <aha...@adobe.com.INVALID>
> >> wrote:
> >>>
> >>> IIRC, it doesn't have to be a bead to be specified in CSS. You just
> >> have to define the property. Then ValuesManager will return the Class
> and
> >> you instantiate. Where you store it after that doesn't matter. It
> doesn't
> >> have to be a strand.
> >>>
> >>> It really comes down to how folks should want to work with
> >> Formatters. Were there any pain points in Flex?
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>> On 1/17/19, 1:40 PM, "Harbs" <harbs.li...@gmail.com <mailto:
> >> harbs.li...@gmail.com>> wrote:
> >>>
> >>> OK, true.
> >>>
> >>> To me the main advantage of it being a bead is the ability to
> >> specify the default in CSS. The idea behind specifying the bead was to
> >> specifically reference it (or override it). Using the bead specified in
> CSS
> >> is difficult if not impossible in MXML.
> >>>
> >>>> On Jan 17, 2019, at 10:50 PM, Alex Harui <aha...@adobe.com.INVALID>
> >> wrote:
> >>>>
> >>>> Not sure I see any advantage of it being a bead there. What
> >> reference to the strand or application does it need? Once you give
> >> anything an id it is "globally" available.
> >>>>
> >>>> <fx:Declarations>
> >>>> <foo:FooFormatter id=“fooFormat”/>
> >>>> </fx:Declarations>
> >>>>
> >>>> <foo:FooComponent>
> >>>> <foo:BazComponent text=“{fooFormat.format(date)}”/>
> >>>> </foo:FooComponent>
> >>>> <foo:SomeOtherFooComponent>
> >>>> <foo:SomeOtherBazComponent text=“{fooFormat.format(date)}”/>
> >>>> </foo:SomeOtherFooComponent>
> >>>>
> >>>> My 2 cents,
> >>>> -Alex
> >>>>
> >>>> On 1/17/19, 12:09 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>>
> >>>> I’d keep it a bead, so you could do something like this (I think):
> >>>> <foo:FooComponent>
> >>>> <js:beads>
> >>>> <foo:FooFormatter id=“fooFormat”/>
> >>>> </js:beads>
> >>>> <foo:BazComponent text=“{fooFormat.format(date)}”/>
> >>>> </foo:FooComponent>
> >>>>
> >>>>> On Jan 17, 2019, at 9:43 PM, Alex Harui <aha...@adobe.com.INVALID>
> >> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 1/17/19, 11:30 AM, "Harbs" <harbs.li...@gmail.com <mailto:
> >> harbs.li...@gmail.com>> wrote:
> >>>>>
> >>>>> Currently, the view must know about the formatter AND the
> >> formatter must know about the view.
> >>>>>
> >>>>> I’m proposing that the view knows there is an IFormatter and just
> >> calls a format() function which is common to all formatters.
> >>>>>
> >>>>> Changing it to the way I’m proposing would also allow for
> >> something like this: text = new FooFormatter.format(baz);
> >>>>>
> >>>>> I think it’s reasonable for a view to know it’s using some
> >> formatter.
> >>>>>
> >>>>> Yeah, I think it is reasonable too. However, calling "new
> >> FooFormatter.format(baz)" is not going to work well with
> >> Formatters-as-beads. And instantiating a formatter each time is
> probably
> >> also going to be painful for Garbage Collection and if the formatter
> needs
> >> to have other properties set (potentially from locale information).
> >>>>>
> >>>>> That's why I recommend thinking this through. We need to agree on
> >> how folks will want to use and maybe share formatters and how to do so
> from
> >> MXML, which is more property-oriented than function-oriented.
> >>>>>
> >>>>> One issue is that DateField wants to instantiate its own
> >> DateFormatter but then that can't be easily shared as the DateFormatter
> in
> >> a user's app.
> >>>>>
> >>>>> HTH,
> >>>>> -Alex
> >>>>>
> >>>>>> On Jan 17, 2019, at 9:10 PM, Alex Harui <aha...@adobe.com.INVALID>
> >> wrote:
> >>>>>>
> >>>>>> I don't like the way it is now. That sounds more like a
> >> validator workflow. Having DateFormatter require IDateChooserModel
> doesn't
> >> sound right. I think the goal of the current implementation was to not
> >> require the views to know about the formatter. Then you could change
> what
> >> the view would display by using a different formatting bead. Maybe
that
> >> was a bad idea. I think you are proposing that the views know they are
> >> using a formatter.
> >>>>>>
> >>>>>> Let's think about how we want Formatters to be used. The first
> >> question that comes to mind is whether the common case is that a single
> >> formatting "algorithm" would be used throughout an application. If so,
> >> then scattering formatting beads on strands in different places in the
> >> application will be painful to manage unless you have a central config
> to
> >> manage them.
> >>>>>>
> >>>>>> IOW, I think it would be rare for dates or currency to be
> >> formatted in one way in some component and differently in some other
> >> component.
> >>>>>>
> >>>>>> The second thing to consider is loose-coupling. How will the
> >> View find a formatter? The advantage of beads is that formatters can
be
> >> replaced, but only if the view finds the formatter by interface name.
> But
> >> then they might be able to find the formatter some other way anyway.
> >> Related: should the presence of a formatter be optional? I think not
in
> >> the common case. The view shouldn't have to worry about the formatter
> not
> >> being there when expected. A view either needs a formatter or it
> doesn’t.
> >>>>>>
> >>>>>> Next question: How should views be able to use formatters when
> >> written in MXML? If there is a shared formatter, that implies function
> >> call binding which is sort of heavy. Having a bead for each property
> being
> >> formatted allows the binding system to use SimpleBinding which is
> >> cheaper/faster. But I think it might be too painful to have a
formatter
> >> instance for each formatted property.
> >>>>>>
> >>>>>> So, maybe it is better to have Views expect formatters. But
> >> maybe formatters should be Singletons so they are shared.
> >>>>>>
> >>>>>> Thoughts?
> >>>>>> -Alex
> >>>>>>
> >>>>>> On 1/17/19, 9:36 AM, "Andrew Wetmore" <cottag...@gmail.com
> >> <mailto:cottag...@gmail.com> <mailto:cottag...@gmail.com <mailto:
> >> cottag...@gmail.com>>> wrote:
> >>>>>>
> >>>>>> This simplification sounds good. Will you be annotating how to
> >> use the new
> >>>>>> bead structures, maybe with some examples, for those of us who
> >> are lost
> >>>>>> among the strands?
> >>>>>>
> >>>>>> On Thu, Jan 17, 2019 at 12:26 PM Harbs <harbs.li...@gmail.com
> >> <mailto:harbs.li...@gmail.com>> wrote:
> >>>>>>
> >>>>>>> I have the occasion this week to deal with the formatter
> >> classes, and I’d
> >>>>>>> like to make some changes. I’d like input from others on the
> >> subject.
> >>>>>>>
> >>>>>>> Taking SimpleDateFormatter as an example:
> >>>>>>> 1. The Formatter assumes that its being attached to a Strand
> >> with an
> >>>>>>> IDateChooserModel.
> >>>>>>> 2. It requires a “propertyName to be set and concatenates that
> >> with
> >>>>>>> “Changed” and adds an event listener to the model.
> >>>>>>> 3. When the property is changed, it formats the result which
> >> must be a
> >>>>>>> “selectedDate” and then dispatches an event.
> >>>>>>> 4. The view bead must attach an event listener to the Formatter
> >> to get
> >>>>>>> notification when the format changes.
> >>>>>>> 5. It also invariably attaches an event listener to the model
> >> when the
> >>>>>>> model changes.
> >>>>>>> 6. When the model changes we have first an event picked up by the
> >>>>>>> formatter and then the formatter dispatches a separate event
> >> which is
> >>>>>>> picked up by the view. The view then explicitly gets the
> >> formatted date
> >>>>>>> from the formatter.
> >>>>>>>
> >>>>>>> That’s a lot of indirection for no apparent reason. It also
> >> limits how a
> >>>>>>> formatter can be used. A DateFormatter can only be used in
> >> conjunction with
> >>>>>>> a IDateChooserModel and it can only format a “selectedDate”. I
> >> ran into
> >>>>>>> issues when trying to figure out how to use the formatters with
> >> date ranges.
> >>>>>>>
> >>>>>>> I want to change it to the following:
> >>>>>>>
> >>>>>>> 1. Make the formatter classes very simple Beads.
> >>>>>>> 2. It will make no assumptions on there being any other beads
> >> and will not
> >>>>>>> attach any event listeners.
> >>>>>>> 3. Likewise, it will not dispatch any events.
> >>>>>>> 4. Date Formatter classes would have a format(date:Date):String
> >> method
> >>>>>>> which would take any valid date and return the formatted string.
> >>>>>>> 5. When a view needs to update a formatted date, it would simply
> >> get the
> >>>>>>> format bead and call format(). This would allow the bead to be
> >> instantiated
> >>>>>>> by any class and would greatly simplify the code.
> >>>>>>>
> >>>>>>> I’d make similar changes to the other formatter classes.
> >>>>>>>
> >>>>>>> Any objections to these changes?
> >>>>>>>
> >>>>>>> Harbs
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Andrew Wetmore
> >>>>>>
> >>>>>>
> >>
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%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
>
>
