Re: Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

[Alex Harui]

Hi Carlos,

Express is not an attempt to emulate Flex APIs.  The Emulation Components are.  
Express is merely designed to pre-compose more beads with less strong-typing in 
the data handling, in response to user feedback we received.  That's why I 
think Jewel should compose Express beads, in order to respond to our users.

Hopefully we will hear from others.

Thanks,
-Alex

On 5/24/18, 3:43 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

I think Jewel born from Basic and started doing the same as Basic do in
order to develop the view, CSS, etc... then is evolving to something that
is usable directly. For example: in the beginning there was Button and
TextButton like in Basic, then I find that only Button (with text property)
was needed since is what we already use it 99% of the time. In the other
hand, things like "Disabled" is already written as a bead since is a
behavior that is needed sometimes. I'm trying to balance so maybe the
response is that is not white, but is not back. So I think is not exactly a
Express set when all is preconfigured. I must say that I'm still learning
from developing Jewel and I'm testing things and sometimes I refactor to
what seems a better solution. In the end I use to think in how the code
finaly looks, and if is usable, flexible and how simple is to write it. So
like in many other fields, iteration over an idea and decision based on
empiric testing use to end in the best solution.

I think Express use to tend mostly to what Flex was, and I think not all in
flex was good, so I hope Jewel could get some things equal, but be better
in other fields. For example, I never liked Validation in Flex, I think is
too tied to the view controls, while Validation should validate date, so be
tied to models instead. As well loved the way this was implemented in
GraniteDS with Metadata, maybe this could be bring to Jewel in bead form,
we'll see when we come to that point.

Other case I'm finding now is for example how to deal with incoming
collections from a Server. In Basic List controls manage ICollectionView,
so we can do what we did in Flex storing data in ArrayLists or instead,
store in simple Array and then making a SingleSelectionArrayListModel,
since normaly that would be what people will use. So people can plug
directly their Array to list.dataprovider, and the control will knows how
to consume the Array. In this case Jewel can give a preselected bead
configuration that should be the use in mostly all cases, since the actual
SingleSelectionCollectionViewModel in Basic is not usable unless
application developers store make a conversion of the incoming Array to
ArrayList to feed the control.

So, in resume I think Jewel is right now in a middle step between Basic and
Express in terms of low-high configuration



2018-05-24 21:48 GMT+02:00 Alex Harui :

> Changing subject in case people have stopped reading.
>
> I think the question in the subject should be decided before we continue
> the package name discussion.  After thinking about it more, I really do
> think that Jewel should default to using Express beads (which might also
> mean that we need to create a few more Express beads).My reasoning is
> that we've already heard from users that a "high-configuration" component
> set like Basic was a pain to work with, which is why started creating a
> "low-configuration" set with Express.  It doesn't make sense to go back to
> "high-configuration" in Jewel.  Jewel should be the one component set 
folks
> use to get to know Royale and it should have both a good default
> look-and-feel (which Carlos has done) but also be "low-configuration".
>  Jewel has enough CSS and complex Views that we shouldn't be worried about
> trying to make Jewel lighter by not using Express beads.  Folks can
> optimize by swapping out beads as needed.
>
> Thoughts?
> -Alex
>
> On 5/22/18, 3:59 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> Hi Alex,
>
> I think we are saying the same in essence.
>
> I want to reuse beads. So lets take "TextPrompt" bead and have only
> one in
> all Royale (always that make the same of course), think that is in a
> library called "Foundation" that depends from Core but is not core.
> Seems
> "Foundation" is a name less confusing than Basic. All UI sets, link
> this
> foundation library and take what they want from it. Normally all UI
> sets
> will borrow "TextPrompt" bead. The same with the pieces in you 
DataGrid
>   

Re: Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

[Carlos Rovira]

Hi Alex,

I think Jewel born from Basic and started doing the same as Basic do in
order to develop the view, CSS, etc... then is evolving to something that
is usable directly. For example: in the beginning there was Button and
TextButton like in Basic, then I find that only Button (with text property)
was needed since is what we already use it 99% of the time. In the other
hand, things like "Disabled" is already written as a bead since is a
behavior that is needed sometimes. I'm trying to balance so maybe the
response is that is not white, but is not back. So I think is not exactly a
Express set when all is preconfigured. I must say that I'm still learning
from developing Jewel and I'm testing things and sometimes I refactor to
what seems a better solution. In the end I use to think in how the code
finaly looks, and if is usable, flexible and how simple is to write it. So
like in many other fields, iteration over an idea and decision based on
empiric testing use to end in the best solution.

I think Express use to tend mostly to what Flex was, and I think not all in
flex was good, so I hope Jewel could get some things equal, but be better
in other fields. For example, I never liked Validation in Flex, I think is
too tied to the view controls, while Validation should validate date, so be
tied to models instead. As well loved the way this was implemented in
GraniteDS with Metadata, maybe this could be bring to Jewel in bead form,
we'll see when we come to that point.

Other case I'm finding now is for example how to deal with incoming
collections from a Server. In Basic List controls manage ICollectionView,
so we can do what we did in Flex storing data in ArrayLists or instead,
store in simple Array and then making a SingleSelectionArrayListModel,
since normaly that would be what people will use. So people can plug
directly their Array to list.dataprovider, and the control will knows how
to consume the Array. In this case Jewel can give a preselected bead
configuration that should be the use in mostly all cases, since the actual
SingleSelectionCollectionViewModel in Basic is not usable unless
application developers store make a conversion of the incoming Array to
ArrayList to feed the control.

So, in resume I think Jewel is right now in a middle step between Basic and
Express in terms of low-high configuration



2018-05-24 21:48 GMT+02:00 Alex Harui :

> Changing subject in case people have stopped reading.
>
> I think the question in the subject should be decided before we continue
> the package name discussion.  After thinking about it more, I really do
> think that Jewel should default to using Express beads (which might also
> mean that we need to create a few more Express beads).My reasoning is
> that we've already heard from users that a "high-configuration" component
> set like Basic was a pain to work with, which is why started creating a
> "low-configuration" set with Express.  It doesn't make sense to go back to
> "high-configuration" in Jewel.  Jewel should be the one component set folks
> use to get to know Royale and it should have both a good default
> look-and-feel (which Carlos has done) but also be "low-configuration".
>  Jewel has enough CSS and complex Views that we shouldn't be worried about
> trying to make Jewel lighter by not using Express beads.  Folks can
> optimize by swapping out beads as needed.
>
> Thoughts?
> -Alex
>
> On 5/22/18, 3:59 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> Hi Alex,
>
> I think we are saying the same in essence.
>
> I want to reuse beads. So lets take "TextPrompt" bead and have only
> one in
> all Royale (always that make the same of course), think that is in a
> library called "Foundation" that depends from Core but is not core.
> Seems
> "Foundation" is a name less confusing than Basic. All UI sets, link
> this
> foundation library and take what they want from it. Normally all UI
> sets
> will borrow "TextPrompt" bead. The same with the pieces in you DataGrid
> example.
>
> In the other hand, UI sets has its own implementation of "Button" (and
> the
> rest of components), and the CSS that wires all the beads used in that
> concrete Button, and the rest of controls and components in that UI
> Set. I
> think we all said that we want to reuse, but we don't want to use a CSS
> from other UI set. So this concrete implementations of controls and
> components and the CSS should go in each library, and so we'll have
> Basic,
> Jewel, MDL, CreateJS,...
>
> Have sense to have Basic CSS and controls in Foundation? for me
> clearly no,
> since Jewel will not use it at all. Will use Foundation classes, (in
> your
> example DataGrid pieces to reuse almost all of it). Will use the CSS
> that
> wires all beads used in Basic, clearly not. So the code that goes in
> each

Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

[Alex Harui]

Changing subject in case people have stopped reading.

I think the question in the subject should be decided before we continue the 
package name discussion.  After thinking about it more, I really do think that 
Jewel should default to using Express beads (which might also mean that we need 
to create a few more Express beads).My reasoning is that we've already 
heard from users that a "high-configuration" component set like Basic was a 
pain to work with, which is why started creating a "low-configuration" set with 
Express.  It doesn't make sense to go back to "high-configuration" in Jewel.  
Jewel should be the one component set folks use to get to know Royale and it 
should have both a good default look-and-feel (which Carlos has done) but also 
be "low-configuration".   Jewel has enough CSS and complex Views that we 
shouldn't be worried about trying to make Jewel lighter by not using Express 
beads.  Folks can optimize by swapping out beads as needed.

Thoughts?
-Alex

On 5/22/18, 3:59 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

I think we are saying the same in essence.

I want to reuse beads. So lets take "TextPrompt" bead and have only one in
all Royale (always that make the same of course), think that is in a
library called "Foundation" that depends from Core but is not core. Seems
"Foundation" is a name less confusing than Basic. All UI sets, link this
foundation library and take what they want from it. Normally all UI sets
will borrow "TextPrompt" bead. The same with the pieces in you DataGrid
example.

In the other hand, UI sets has its own implementation of "Button" (and the
rest of components), and the CSS that wires all the beads used in that
concrete Button, and the rest of controls and components in that UI Set. I
think we all said that we want to reuse, but we don't want to use a CSS
from other UI set. So this concrete implementations of controls and
components and the CSS should go in each library, and so we'll have Basic,
Jewel, MDL, CreateJS,...

Have sense to have Basic CSS and controls in Foundation? for me clearly no,
since Jewel will not use it at all. Will use Foundation classes, (in your
example DataGrid pieces to reuse almost all of it). Will use the CSS that
wires all beads used in Basic, clearly not. So the code that goes in each
UI set library is clearly not reusable at all, and we don't want the
compiler to take extra time processing the CSS that wires all beads from a
UI Set that will not be used right?.

The opposite will be "lets take all ui set implementations (Basic, Jewel,
MDL, CreateJS,...) and mix altogether in a unique Foundation library with
all control and components implementations and all the CSSs that wires the
beads". Make this sense? For me clearly not. Moreover, in this case why
have libraries for Network, Binding, Collections...? Hope this extreme case
showcased makes more sense to explain.

If we want to reuse lets go and reuse, I'm all for it, but we shouldn't
have the CSS that binds all together for a UI Set that will not be used
since doesn't support anything in the normal use. And all of this even if
we get rid of the current bugs that brings lots of things to the final bake.

I think a library or SWC is in essence a reusable piece, but we not link
all existing SWC for all projects since we know we'll not using *all*
available SWCs we have, and since we don't want the compiler process all
CSSs in all that libraries all the time, since is time consuming. For this
reason we create the current SWC libraries, since if people will not use
Network, they normally don't link, if they use Basic, but not Jewel, MDL,
and CreateJS, those are not linked.

Finaly, if I'll not use Basic...then I don't want to be obligated to link
Basic (basic controls, and CSS) but I want to link Foundation since are the
reusable pieces in all Royale UI Sets.

Hope this explanation make more sense.

Thanks

Carlos







2018-05-22 23:43 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I guess I don't understand why separating beads from TLCs is better.  How
> will that make things better for users or other component set developers?
> That would effectively double the number of SWCs and each TLC SWC will 
need
> its bead SWC.  That doesn't sound like a good thing to me, but if that's
> what other folks want to do, that's fine with me.
>
> I was just looking through the classes in Jewel.  It looks like JeweL
> doesn't have a DataGrid yet..  When it does, I would think you will want 
to
> use the DataGridModel from Express as it handles both Arrays and
>