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 (<cottag...@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 <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
>
> http://cottage14.blogspot.com/
>
--
Carlos Rovira
http://about.me/carlosrovira
