Convert s:DateChooser to js:DateChooser

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Convert s:DateChooser to js:DateChooser

doug777
I have a DateChooser that looks like this

<s:DateChooser id="dcCal1"
                headerColors="[0xdee7f6, 0xacc9f6]"
                showToday="false"
                contentBackgroundColor="0xffe189"
                selectionColor="0x83fc61"
                change="dateChangeEventHandler(event)"
                valueCommit="cbChangeEventHandler(event)"
                scroll="dateFieldScrollHandler(event)"/>

Taking the attributes one by one

headerColours - Do I set the CSS background-color style on the
DateChooserHeader bead? Is there now any easy way to set a color gradient or
do I have to create and set a background-image?

showToday - Presumably this is not set in flexjs so I can omit this, but
when I want to set it later in actionscript, is there an easy way to do it?

contentBackgroundColor - Do I set the CSS background-color style on the
DateChooserList bead?

selectionColor - How do I set this?

change - I guess I just set this in the main tag or do I have to set it on
the DateChooserList bead?

valueCommit - Previously the change event fired only on user changes.
valueCommit event was needed for programmatic changes. If the js change
event works the same way as before, how do I set a valueCommit event?

scroll - I only want this event to fire when the Next/Previous Month buttons
are clicked. Do I set the click event on the DateChooserButton bead to
achieve this? Presumably the click event on the main tag affects the whole
calendar, but it looks as though the DateChooserButton is just for the
header buttons - is that right?

Can anyone say whether I'm right or wrong on each point and give some
pointer as to which direction I should take to solve the issues.

Thanks,
Doug



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Peter Ent
Hi Doug,

I'll try and answer your questions in-line, below. In Royale, a "bead" add
functionality or a visual component to another component. Some components
are actually composites made from other components. DateChooser is like
that: the DateChooserHeader and DateChooserList are themselves components
with beads. A bead would be more like the Password bead that you can add
to a TextInput component which intercepts your keystrokes and replaces
them with "*".

As you'll see from my answers in-line, I have a couple of things to check
for you. But the Royale DateChooser should be serviceable for you right
now and it needs a little more work to come up to par with the Flex
DateChooser.

Regards,
Peter Ent
Adobe Systems/Apache Royale Project

On 10/25/17, 4:19 AM, "doug777" <[hidden email]> wrote:

>I have a DateChooser that looks like this
>
><s:DateChooser id="dcCal1"
> headerColors="[0xdee7f6, 0xacc9f6]"
> showToday="false"
> contentBackgroundColor="0xffe189"
> selectionColor="0x83fc61"
> change="dateChangeEventHandler(event)"
> valueCommit="cbChangeEventHandler(event)"
> scroll="dateFieldScrollHandler(event)"/>
>
>Taking the attributes one by one
>
>headerColours - Do I set the CSS background-color style on the
>DateChooserHeader bead? Is there now any easy way to set a color gradient
>or
>do I have to create and set a background-image?

You are correct that you need to set the style on the DateChooserHeader
(it is not a bead, but a component in its own right). Right now we do not
have a gradient background bead. We also do not support a background image
yet on the SWF platform; it should work for the HTML platform although I
have not tried that. If you can set gradient colors in CSS (not an expert
in this, I'm afraid), then that might work, too.
>
>showToday - Presumably this is not set in flexjs so I can omit this, but
>when I want to set it later in actionscript, is there an easy way to do
>it?

We haven't written any way to distinguish "today" from any other
selection. This, to me, is a gray area in terms of pay-as-you-go.
Presumably, most DateChoosers would want to show "today" and if that's the
case, the functionality would be built in. But if most DateChoosers would
not do that, then the pay-as-you-go philosophy would have it as a bead
that would make it happen just for those DateChooser instances that
require it.
>
>contentBackgroundColor - Do I set the CSS background-color style on the
>DateChooserList bead?

Yes - set the background color for DateChooserList (also, not a bead but a
component).
>
>selectionColor - How do I set this?

Not sure - its been awhile since I looked at that code and will have to
get back to you.
>
>change - I guess I just set this in the main tag or do I have to set it on
>the DateChooserList bead?

You put the change event handler on the DateChooser itself, just like with
Flex. In general, events that sub-components or beads issue are dispatched
by the main component (strand) itself so there is one central place to
listen for events. Sometimes events internal to the function of the
component are dispatched on some other part and then transformed and
dispatched off the strand.
>
>valueCommit - Previously the change event fired only on user changes.
>valueCommit event was needed for programmatic changes. If the js change
>event works the same way as before, how do I set a valueCommit event?

I don't think we are issuing valueCommit events in Royale; I'll have to
check on that, too.
>
>scroll - I only want this event to fire when the Next/Previous Month
>buttons
>are clicked. Do I set the click event on the DateChooserButton bead to
>achieve this? Presumably the click event on the main tag affects the whole
>calendar, but it looks as though the DateChooserButton is just for the
>header buttons - is that right?

I'm pretty sure no events are being dispatched when the month changes. I
think it should and this would be a bug, IMO.

>
>Can anyone say whether I'm right or wrong on each point and give some
>pointer as to which direction I should take to solve the issues.
>
>Thanks,
>Doug
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7C82c7a329566f48cda6a708d
>51b811474%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636445163578601369&
>sdata=CzM9UtTY5E7uG3iCdfMmeVn9I9wbHyaC4MwIYdkrdXc%3D&reserved=0

Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

doug777
Hi Peter,

Many thanks for your clear explanation about the difference between
sub-components and beads. I hadn't understood that at all before.

headerColors - I'm only interested in HTML for this project so the
background-image solution is the simplest and most reliable. CSS gradients
are very dependent on the browser being used, I think. A gradient bead might
be worthwhile if it could be used in lots of different components. It's not
clear to me whether existing beads are specific to a particular component or
can be used in any component where that function would be applicable.

selectionColor - This is a nice feature, but perhaps I can find another way
to do it if it's not available yet.

showToday - This is a very minor issue. I can live without it and if you do
plan to implement it, I would put it on low priority.

valueCommit - I would have thought the best solution would be to make the
change event work for both user and programmatic changes. From the
developer's point of view, you know when you make a programmatic change so
if you need to differentiate you obviously can. But of course I don't know
how much more complicated the change event needs to be to handle both
things.

scroll - This one is essential. In my case on opening the calendar, I open
with two consecutive months to view so I need to take care of changing the
month in one calendar when a month button is clicked in the other one. There
are many, many websites that use twin calendars like this, so I think this
must be a very common requirement.

Thanks for your help,
Doug



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Justin Mclean
Hi,

I ‘ve just submitted a pull request for dispatching an event on month change that may help you. [1]

Thanks,
Justin

1. https://github.com/apache/royale-asjs/pull/53
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

doug777
Hey Justin,

That's fantastic. Big thank-you from me.

Doug



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Peter Ent
After looking over what you want, I think this isn't falling into the PAYG
philosophy. Most users of DateChooser won't need to dispatch a
monthChanged event. The thing to do is subclass the DateChooserView and
make that dispatch the monthChanged event.

The Basic package is supposed to deliver the most common features with the
least overhead. Sometimes the code we/I wrote isn't as performant as it
could be, so that would be a PAYG improvement to make it smaller or faster
(or there could be a bug in that an event that is supposed to be
dispatched isn't). But adding more events and properties just enlarges the
components which is not PAYG.

If you think a particular property or event would benefit every user of
the component, then we can have a discussion about adding that to Basic.

On the other hand, the Express version of DateChooser could be extended to
extras (like a monthChanged event) out of the box. And this probably is
true of other requests for DateChooser. The Express package is meant to be
a quicker way to get started with Royale since a number of the components
there have more beads and features packaged into them; Express is not PAYG
in that sense.

We can also consider creating another package that tries to mimic old Flex
as closely as possible.

The bottom line is, we want to keep Basic really basic and provide the
underpinnings for creating a fast and fluid application, adding to it only
when and where necessary. A lot of that may fall onto the shoulders of app
developers, more so than it did with Flex.

‹peter

On 10/26/17, 4:46 AM, "doug777" <[hidden email]> wrote:

>Hey Justin,
>
>That's fantastic. Big thank-you from me.
>
>Doug
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7Ce6634fbdf06c4f411e7508d
>51c4e1b43%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446044150566225&
>sdata=CjeJaHA3joQpC3ChCzaix7%2BZvg97Gm3P5lSUXwZlBBw%3D&reserved=0

Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Piotr Zarzycki

Peter,

You have mention about monthChaned event. I didn't check myself, but in most of our components we are using only change event. It is probably quite common event in html world - What actually is doing change event in DateChooser? Maybe that is the answer for all changes?

Thanks, Piotr


On Thu, Oct 26, 2017, 18:14 Peter Ent <[hidden email]> wrote:
After looking over what you want, I think this isn't falling into the PAYG
philosophy. Most users of DateChooser won't need to dispatch a
monthChanged event. The thing to do is subclass the DateChooserView and
make that dispatch the monthChanged event.

The Basic package is supposed to deliver the most common features with the
least overhead. Sometimes the code we/I wrote isn't as performant as it
could be, so that would be a PAYG improvement to make it smaller or faster
(or there could be a bug in that an event that is supposed to be
dispatched isn't). But adding more events and properties just enlarges the
components which is not PAYG.

If you think a particular property or event would benefit every user of
the component, then we can have a discussion about adding that to Basic.

On the other hand, the Express version of DateChooser could be extended to
extras (like a monthChanged event) out of the box. And this probably is
true of other requests for DateChooser. The Express package is meant to be
a quicker way to get started with Royale since a number of the components
there have more beads and features packaged into them; Express is not PAYG
in that sense.

We can also consider creating another package that tries to mimic old Flex
as closely as possible.

The bottom line is, we want to keep Basic really basic and provide the
underpinnings for creating a fast and fluid application, adding to it only
when and where necessary. A lot of that may fall onto the shoulders of app
developers, more so than it did with Flex.

‹peter

On 10/26/17, 4:46 AM, "doug777" <[hidden email]> wrote:

>Hey Justin,
>
>That's fantastic. Big thank-you from me.
>
>Doug
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7Ce6634fbdf06c4f411e7508d
>51c4e1b43%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446044150566225&
>sdata=CjeJaHA3joQpC3ChCzaix7%2BZvg97Gm3P5lSUXwZlBBw%3D&reserved=0

Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Harbs
The DateChooser has both months and years. Presumably, the change event should apply to the specific date selected (although the event is actually called “selectedDateChanged”), while the “month" and “year” events are display events (hence the names displayMonthChanged and displayYearChanged).

On Oct 26, 2017, at 7:41 PM, Piotr Zarzycki <[hidden email]> wrote:

Peter,

You have mention about monthChaned event. I didn't check myself, but in most of our components we are using only change event. It is probably quite common event in html world - What actually is doing change event in DateChooser? Maybe that is the answer for all changes?

Thanks, Piotr


On Thu, Oct 26, 2017, 18:14 Peter Ent <[hidden email]> wrote:
After looking over what you want, I think this isn't falling into the PAYG
philosophy. Most users of DateChooser won't need to dispatch a
monthChanged event. The thing to do is subclass the DateChooserView and
make that dispatch the monthChanged event.

The Basic package is supposed to deliver the most common features with the
least overhead. Sometimes the code we/I wrote isn't as performant as it
could be, so that would be a PAYG improvement to make it smaller or faster
(or there could be a bug in that an event that is supposed to be
dispatched isn't). But adding more events and properties just enlarges the
components which is not PAYG.

If you think a particular property or event would benefit every user of
the component, then we can have a discussion about adding that to Basic.

On the other hand, the Express version of DateChooser could be extended to
extras (like a monthChanged event) out of the box. And this probably is
true of other requests for DateChooser. The Express package is meant to be
a quicker way to get started with Royale since a number of the components
there have more beads and features packaged into them; Express is not PAYG
in that sense.

We can also consider creating another package that tries to mimic old Flex
as closely as possible.

The bottom line is, we want to keep Basic really basic and provide the
underpinnings for creating a fast and fluid application, adding to it only
when and where necessary. A lot of that may fall onto the shoulders of app
developers, more so than it did with Flex.

‹peter

On 10/26/17, 4:46 AM, "doug777" <[hidden email]> wrote:

>Hey Justin,
>
>That's fantastic. Big thank-you from me.
>
>Doug
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7Ce6634fbdf06c4f411e7508d
>51c4e1b43%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446044150566225&
>sdata=CjeJaHA3joQpC3ChCzaix7%2BZvg97Gm3P5lSUXwZlBBw%3D&reserved=0


Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Peter Ent
The change event is dispatched when a date is selected. That's the only public event. Due to the way the DateChooser is constructed, the header part (with the month selection buttons) updates the model which sends a "displayedMonthChanged" event. The view is looking for this event and then regenerates the data for the List displaying the month.  Same for the year.

—peter

From: Harbs <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, October 26, 2017 at 1:41 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Convert s:DateChooser to js:DateChooser

The DateChooser has both months and years. Presumably, the change event should apply to the specific date selected (although the event is actually called “selectedDateChanged”), while the “month" and “year” events are display events (hence the names displayMonthChanged and displayYearChanged).

On Oct 26, 2017, at 7:41 PM, Piotr Zarzycki <[hidden email]> wrote:

Peter,

You have mention about monthChaned event. I didn't check myself, but in most of our components we are using only change event. It is probably quite common event in html world - What actually is doing change event in DateChooser? Maybe that is the answer for all changes?

Thanks, Piotr


On Thu, Oct 26, 2017, 18:14 Peter Ent <[hidden email]> wrote:
After looking over what you want, I think this isn't falling into the PAYG
philosophy. Most users of DateChooser won't need to dispatch a
monthChanged event. The thing to do is subclass the DateChooserView and
make that dispatch the monthChanged event.

The Basic package is supposed to deliver the most common features with the
least overhead. Sometimes the code we/I wrote isn't as performant as it
could be, so that would be a PAYG improvement to make it smaller or faster
(or there could be a bug in that an event that is supposed to be
dispatched isn't). But adding more events and properties just enlarges the
components which is not PAYG.

If you think a particular property or event would benefit every user of
the component, then we can have a discussion about adding that to Basic.

On the other hand, the Express version of DateChooser could be extended to
extras (like a monthChanged event) out of the box. And this probably is
true of other requests for DateChooser. The Express package is meant to be
a quicker way to get started with Royale since a number of the components
there have more beads and features packaged into them; Express is not PAYG
in that sense.

We can also consider creating another package that tries to mimic old Flex
as closely as possible.

The bottom line is, we want to keep Basic really basic and provide the
underpinnings for creating a fast and fluid application, adding to it only
when and where necessary. A lot of that may fall onto the shoulders of app
developers, more so than it did with Flex.

‹peter

On 10/26/17, 4:46 AM, "doug777" <[hidden email]> wrote:

>Hey Justin,
>
>That's fantastic. Big thank-you from me.
>
>Doug
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7Ce6634fbdf06c4f411e7508d
>51c4e1b43%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446044150566225&
>sdata=CjeJaHA3joQpC3ChCzaix7%2BZvg97Gm3P5lSUXwZlBBw%3D&reserved=0


Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Piotr Zarzycki

Maybe stupid question - where is the problem? What are we trying to set up here?

1) Have one event "change" which is dispatch from View in the result of some events happen from model etc. ?

2) Have bunch of separate events "displayMonthChanged " etc. ?

I mean here events exposed to user, not those one dispatched in model.

Thanks for explanation so far,

Piotr


On Thu, Oct 26, 2017, 20:00 Peter Ent <[hidden email]> wrote:
The change event is dispatched when a date is selected. That's the only public event. Due to the way the DateChooser is constructed, the header part (with the month selection buttons) updates the model which sends a "displayedMonthChanged" event. The view is looking for this event and then regenerates the data for the List displaying the month.  Same for the year.

—peter

From: Harbs <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, October 26, 2017 at 1:41 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Convert s:DateChooser to js:DateChooser

The DateChooser has both months and years. Presumably, the change event should apply to the specific date selected (although the event is actually called “selectedDateChanged”), while the “month" and “year” events are display events (hence the names displayMonthChanged and displayYearChanged).

On Oct 26, 2017, at 7:41 PM, Piotr Zarzycki <[hidden email]> wrote:

Peter,

You have mention about monthChaned event. I didn't check myself, but in most of our components we are using only change event. It is probably quite common event in html world - What actually is doing change event in DateChooser? Maybe that is the answer for all changes?

Thanks, Piotr


On Thu, Oct 26, 2017, 18:14 Peter Ent <[hidden email]> wrote:
After looking over what you want, I think this isn't falling into the PAYG
philosophy. Most users of DateChooser won't need to dispatch a
monthChanged event. The thing to do is subclass the DateChooserView and
make that dispatch the monthChanged event.

The Basic package is supposed to deliver the most common features with the
least overhead. Sometimes the code we/I wrote isn't as performant as it
could be, so that would be a PAYG improvement to make it smaller or faster
(or there could be a bug in that an event that is supposed to be
dispatched isn't). But adding more events and properties just enlarges the
components which is not PAYG.

If you think a particular property or event would benefit every user of
the component, then we can have a discussion about adding that to Basic.

On the other hand, the Express version of DateChooser could be extended to
extras (like a monthChanged event) out of the box. And this probably is
true of other requests for DateChooser. The Express package is meant to be
a quicker way to get started with Royale since a number of the components
there have more beads and features packaged into them; Express is not PAYG
in that sense.

We can also consider creating another package that tries to mimic old Flex
as closely as possible.

The bottom line is, we want to keep Basic really basic and provide the
underpinnings for creating a fast and fluid application, adding to it only
when and where necessary. A lot of that may fall onto the shoulders of app
developers, more so than it did with Flex.

‹peter

On 10/26/17, 4:46 AM, "doug777" <[hidden email]> wrote:

>Hey Justin,
>
>That's fantastic. Big thank-you from me.
>
>Doug
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7Ce6634fbdf06c4f411e7508d
>51c4e1b43%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446044150566225&
>sdata=CjeJaHA3joQpC3ChCzaix7%2BZvg97Gm3P5lSUXwZlBBw%3D&reserved=0


Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Peter Ent
There is only 1 actionable event dispatched by DateChooser: change. This happens when the user picks a date from the calendar. I just added a fix that makes the DateChooser's selectedDate bindable which is consistent with List that has selectedIndex and selectedItem bindable properties.

What I'm saying is that other events, like monthChanged or yearChanged would be rarely used so not PAYG. Doing so would start on the road to bloating the Basic package components. The better PAYG thing is to have an Express version of DateChooser that has the extra events (and maybe other features).

—peter

From: Piotr Zarzycki <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, October 26, 2017 at 3:13 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Convert s:DateChooser to js:DateChooser

Maybe stupid question - where is the problem? What are we trying to set up here?

1) Have one event "change" which is dispatch from View in the result of some events happen from model etc. ?

2) Have bunch of separate events "displayMonthChanged " etc. ?

I mean here events exposed to user, not those one dispatched in model.

Thanks for explanation so far,

Piotr


On Thu, Oct 26, 2017, 20:00 Peter Ent <[hidden email]> wrote:
The change event is dispatched when a date is selected. That's the only public event. Due to the way the DateChooser is constructed, the header part (with the month selection buttons) updates the model which sends a "displayedMonthChanged" event. The view is looking for this event and then regenerates the data for the List displaying the month.  Same for the year.

—peter

From: Harbs <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, October 26, 2017 at 1:41 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Convert s:DateChooser to js:DateChooser

The DateChooser has both months and years. Presumably, the change event should apply to the specific date selected (although the event is actually called “selectedDateChanged”), while the “month" and “year” events are display events (hence the names displayMonthChanged and displayYearChanged).

On Oct 26, 2017, at 7:41 PM, Piotr Zarzycki <[hidden email]> wrote:

Peter,

You have mention about monthChaned event. I didn't check myself, but in most of our components we are using only change event. It is probably quite common event in html world - What actually is doing change event in DateChooser? Maybe that is the answer for all changes?

Thanks, Piotr


On Thu, Oct 26, 2017, 18:14 Peter Ent <[hidden email]> wrote:
After looking over what you want, I think this isn't falling into the PAYG
philosophy. Most users of DateChooser won't need to dispatch a
monthChanged event. The thing to do is subclass the DateChooserView and
make that dispatch the monthChanged event.

The Basic package is supposed to deliver the most common features with the
least overhead. Sometimes the code we/I wrote isn't as performant as it
could be, so that would be a PAYG improvement to make it smaller or faster
(or there could be a bug in that an event that is supposed to be
dispatched isn't). But adding more events and properties just enlarges the
components which is not PAYG.

If you think a particular property or event would benefit every user of
the component, then we can have a discussion about adding that to Basic.

On the other hand, the Express version of DateChooser could be extended to
extras (like a monthChanged event) out of the box. And this probably is
true of other requests for DateChooser. The Express package is meant to be
a quicker way to get started with Royale since a number of the components
there have more beads and features packaged into them; Express is not PAYG
in that sense.

We can also consider creating another package that tries to mimic old Flex
as closely as possible.

The bottom line is, we want to keep Basic really basic and provide the
underpinnings for creating a fast and fluid application, adding to it only
when and where necessary. A lot of that may fall onto the shoulders of app
developers, more so than it did with Flex.

‹peter

On 10/26/17, 4:46 AM, "doug777" <[hidden email]> wrote:

>Hey Justin,
>
>That's fantastic. Big thank-you from me.
>
>Doug
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7Ce6634fbdf06c4f411e7508d
>51c4e1b43%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446044150566225&
>sdata=CjeJaHA3joQpC3ChCzaix7%2BZvg97Gm3P5lSUXwZlBBw%3D&reserved=0


Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

doug777
Just like to pick up on some of the things you said.

> The thing to do is subclass the DateChooserView and
> make that dispatch the monthChanged event.
That's fair enough, but how could someone like me know that's what is
required? Without your input, I would have guessed that I would have to play
with the DateChooserHeader, not the DateChooserView. But my point is that
surely I don't have to learn to understand the technical internal details of
every component. Even if you plan to cover this in documentation eventually,
it will surely be an enormous task to cover every possibility that old Flex
made simple and intuitive.

> The Basic package is supposed to deliver the most common features with the
> least overhead. But adding more events and properties just enlarges the
> components which is not PAYG.
The way I had thought this was intended to work was that the Basic component
would contain only that which was essential for the component to work and
that everything else would be provided by beads. So instead of selecting
from a palette of additional functionality that is already there (old Flex),
you would choose from the range of beads (which would eventually cover most
of what was available for old Flex) and these could be added to the basic
component by the app developer as required. So monthChanged would be a
separate bead or part of a 'header events' bead. (But is there really any
purpose in the yearChanged event, an event triggered by any button in the
header is surely sufficient.)

> On the other hand, the Express version of DateChooser could be extended to
> extras (like a monthChanged event) out of the box.
The Express version seems to me to be a range of components with some of the
existing beads already included. Why would I choose to use this over a Basic
component where I can just add whatever ones of the existing beads that I
want?

> We can also consider creating another package that tries to mimic old Flex
> as closely as possible.
But haven't you already laid the foundation for this with the Basic
component and beads. Surely 'all' you have to do is add more beads till they
cover whatever useful functionality old Flex had.

Doug





--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Justin Mclean
Hi,

>> The thing to do is subclass the DateChooserView and
>> make that dispatch the monthChanged event.

Which as far a s I can see would required more code than the current proposed change.

The new class DateChooserXXXX would need to:
a) extend DateChooser and have the meta tag for the event

You would also need to add a new class DateChooserVIewXXX that would need to:
a) dispatch the event on header change

However the method handleModelChange is private so this would require changing this or overriding and duplication the code in set strand.

BTW re the event name changes I just thought that this:

 <js:DateChooser id="dc1" height="200" monthChanged="monthChange()" />

Was better than:

 <js:DateChooser id="dc1" height="200” displayMonthChanged="monthChange()" />

But no big deal if you want to keep the old names.

> But haven't you already laid the foundation for this with the Basic
> component and beads. Surely 'all' you have to do is add more beads till they
> cover whatever useful functionality old Flex had.

Having a look at this I can’t see any way that this could be easily added as a bead but it may be possible.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Justin Mclean
In reply to this post by doug777
Hi,

> selectionColor - How do I set this?

I just submitted a path that should allow you to do this (and the hover  colour). It turns out the colours were hardcoded into the AS code.[1]

Although I’m not 100% sure how you can set properties on the item renderer from the DataChooser. I’ll look into that next.

Thanks,
Justin

1. https://github.com/apache/royale-asjs/pull/56
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

doug777
Hi Justin,

That all sounds great.

I am strongly in favour of the strands and beads approach, which was, and is
a brilliant idea.

But it should gradually try to approach the usability of old Flex, though I
realize there are some Flash things that can't be done in javascript.

So anything that goes along that path sticking as closely as possible to the
PAYG concept is good news for everyone.

Doug



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Peter Ent
In reply to this post by doug777
I, too, sometimes drift off the PAYG path. Keep in mind that a "component"
is really a very light "strand" (often the actual thing on the display
list) augmented by beads. One of the beads is a IBeadView that should make
the visuals. Like the NumericStepper's view bead creates the text input
and spinner buttons and then lays them out in a particular order. If you
wanted a different look to the NumericStepper you would create a different
view bead that puts the items in different places.

The model is key and the beads of a component should communicate through
the model. The model's changes dispatch events the beads can use. If you
wanted the DateChooser to send a monthChanged event, it should be possible
using a bead: the bead listens on the model for the displayedMonthChanged
and then dispatches "monthChanged" on the strand. I was not thinking
clearly when I suggested re-writing a new view bead.

I think Basic needs more tuning so that its easier to do these things.
Some of the components might actually need to be scaled back and more
beads set up. Plus we need a catalog for all the beads we have to make it
easier to choose which ones to use.

The Express package is for people new to Royale who just want to get an
app going and don't realize they may need data binding beads and such to
get an app working. Its supposed to be "faster" to use it, hence
"Express". And this case, you pay more for Express in terms of download
size and perhaps performance because every instance has a lot of code you
might not use. For example, if you want to build a form and have a dozen
TextInput fields, but only two with password capability, the Express
TextInput will have that in every instance of TextInput but using Basic
only two TextInput components would have the password beads added.

I hope this is clearer. Royale is not finished and needs more polish.
Sometimes it can be frustrating getting the parts to work, but as more
people work on it, the cleaner it will become. We have to be careful to
first try and create a new bead before adding more onto existing beads or
strands.

‹peter

On 10/27/17, 12:03 AM, "doug777" <[hidden email]> wrote:

>Just like to pick up on some of the things you said.
>
>> The thing to do is subclass the DateChooserView and
>> make that dispatch the monthChanged event.
>That's fair enough, but how could someone like me know that's what is
>required? Without your input, I would have guessed that I would have to
>play
>with the DateChooserHeader, not the DateChooserView. But my point is that
>surely I don't have to learn to understand the technical internal details
>of
>every component. Even if you plan to cover this in documentation
>eventually,
>it will surely be an enormous task to cover every possibility that old
>Flex
>made simple and intuitive.
>
>> The Basic package is supposed to deliver the most common features with
>>the
>> least overhead. But adding more events and properties just enlarges the
>> components which is not PAYG.
>The way I had thought this was intended to work was that the Basic
>component
>would contain only that which was essential for the component to work and
>that everything else would be provided by beads. So instead of selecting
>from a palette of additional functionality that is already there (old
>Flex),
>you would choose from the range of beads (which would eventually cover
>most
>of what was available for old Flex) and these could be added to the basic
>component by the app developer as required. So monthChanged would be a
>separate bead or part of a 'header events' bead. (But is there really any
>purpose in the yearChanged event, an event triggered by any button in the
>header is surely sufficient.)
>
>> On the other hand, the Express version of DateChooser could be extended
>>to
>> extras (like a monthChanged event) out of the box.
>The Express version seems to me to be a range of components with some of
>the
>existing beads already included. Why would I choose to use this over a
>Basic
>component where I can just add whatever ones of the existing beads that I
>want?
>
>> We can also consider creating another package that tries to mimic old
>>Flex
>> as closely as possible.
>But haven't you already laid the foundation for this with the Basic
>component and beads. Surely 'all' you have to do is add more beads till
>they
>cover whatever useful functionality old Flex had.
>
>Doug
>
>
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7C1e230aaf21c948e795f508d
>51cefae9f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446738110416018&
>sdata=8580Mxtr6ks61W6b6Bbpk0B3SuVFpdcCgiXKF3XtaI8%3D&reserved=0

Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

doug777
Thanks Peter, that's very helpful.

I do think Basic is the thing to put the most effort into whilst maintaining
the PAYG approach. If this were to be deeply integrated into Moonshine then
this could show users what beads are available for each strand.

Whilst FlexJS users can use other IDEs and Moonshine needs to be able to
handle the other things: MDL, Express etc., Basic with its own IDE can be a
really powerful tool for app developers of all ability levels.

If Basic and Moonshine could be as good or better than old Flex was with its
integrated IDE on Eclipse before Adobe was forced to abandon Flash, then I
think you've got a world-beater here. Although at this time as soon as you
start to use it, you run into all sorts of bugs and difficulties, at the
same time you can see the enormous potential of it.

It's a brilliant job so far by all the team and I am very excited to see it
progress to a release version and beyond.

Doug



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Piotr Zarzycki


2017-10-30 2:58 GMT+01:00 doug777 <[hidden email]>:
Thanks Peter, that's very helpful.

I do think Basic is the thing to put the most effort into whilst maintaining
the PAYG approach. If this were to be deeply integrated into Moonshine then
this could show users what beads are available for each strand.

Whilst FlexJS users can use other IDEs and Moonshine needs to be able to
handle the other things: MDL, Express etc., Basic with its own IDE can be a
really powerful tool for app developers of all ability levels.

If Basic and Moonshine could be as good or better than old Flex was with its
integrated IDE on Eclipse before Adobe was forced to abandon Flash, then I
think you've got a world-beater here. Although at this time as soon as you
start to use it, you run into all sorts of bugs and difficulties, at the
same time you can see the enormous potential of it.

It's a brilliant job so far by all the team and I am very excited to see it
progress to a release version and beyond.



--

Piotr Zarzycki 

mobile: +48 880 859 557 
skype: zarzycki10

LinkedIn: http://www.linkedin.com/piotrzarzycki

GitHubhttps://github.com/piotrzarzycki21

Reply | Threaded
Open this post in threaded view
|

Re: Convert s:DateChooser to js:DateChooser

Piotr Zarzycki
Hi Doug,

It is wonderful that you noticed that even that there are a lot of issues there you are seeing that potential in it! 

Thank you!, Piotr

2017-10-30 10:17 GMT+01:00 Piotr Zarzycki <[hidden email]>:


2017-10-30 2:58 GMT+01:00 doug777 <[hidden email]>:
Thanks Peter, that's very helpful.

I do think Basic is the thing to put the most effort into whilst maintaining
the PAYG approach. If this were to be deeply integrated into Moonshine then
this could show users what beads are available for each strand.

Whilst FlexJS users can use other IDEs and Moonshine needs to be able to
handle the other things: MDL, Express etc., Basic with its own IDE can be a
really powerful tool for app developers of all ability levels.

If Basic and Moonshine could be as good or better than old Flex was with its
integrated IDE on Eclipse before Adobe was forced to abandon Flash, then I
think you've got a world-beater here. Although at this time as soon as you
start to use it, you run into all sorts of bugs and difficulties, at the
same time you can see the enormous potential of it.

It's a brilliant job so far by all the team and I am very excited to see it
progress to a release version and beyond.



--

Piotr Zarzycki 

mobile: <a href="tel:+48%20880%20859%20557" value="+48880859557" target="_blank">+48 880 859 557 
skype: zarzycki10

LinkedIn: http://www.linkedin.com/piotrzarzycki

GitHubhttps://github.com/piotrzarzycki21




--

Piotr Zarzycki 

mobile: +48 880 859 557 
skype: zarzycki10

LinkedIn: http://www.linkedin.com/piotrzarzycki

GitHubhttps://github.com/piotrzarzycki21