Re: Formatter Classes

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

Re: Formatter Classes

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; Thanks, Piotr On Fri, Jan 18, 2019, 6:17 PM Alex Harui wrote: > @Piotr: What warning do you expect? I think it would

Re: Formatter Classes

@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

Re: Formatter Classes

Hi Guys, Going in that way: We probably have Bindable warning - Am I right? Thanks, Piotr On Fri, Jan 18, 2019, 2:37 PM Harbs 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

Re: Formatter Classes

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 wrote: > > Hi, > just

Re: Formatter Classes

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 () escribió: > You can override in MXML if the code

Re: Formatter Classes

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" wrote: Interesting. I never considered that. Although there’s then no way to override in MXML. I think keeping it a bead leaves

Re: Formatter Classes

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 wrote: > > IIRC, it doesn't have to be a bead to be specified in

Re: Formatter Classes

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

Re: Formatter Classes

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,

Re: Formatter Classes

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. My 2 cents, -Alex On 1/17/19, 12:09 PM, "Harbs" wrote: I’d keep it a bead, so you could

Re: Formatter Classes

I’d keep it a bead, so you could do something like this (I think): > On Jan 17, 2019, at 9:43 PM, Alex Harui wrote: > > > > On 1/17/19, 11:30 AM, "Harbs" > wrote: > >Currently, the view must know about the formatter AND the formatter must >

Re: Formatter Classes

On 1/17/19, 11:30 AM, "Harbs" 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

Re: Formatter Classes

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

Re: Formatter Classes

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

Re: Formatter Classes

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 DateFormatDDMM (Our config for the records in app is: j|DateField IFormatBead:

Re: Formatter Classes

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 wrote: > I have the occasion this week to deal with the formatter classes, and I’d > like