IIRC, functions/methods can be given [Bindable] metadata and avoid warnings.
HTH,
-Alex
On 1/18/19, 9:21 AM, "Piotr Zarzycki" <piotrzarzyck...@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 <aha...@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" <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%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
> >
> >
>
>
>
