Well, I agree that most FlexJS users will not be more productive having to
assemble everything from tons of little beads, and that's why I've been
saying for quite a while that I expect heavier component sets like Express
to be more popular.
That said, we don't want the compiler generating code. With FlexJS, we
are trying hard not to generate any code out of the compiler. I think I
have it down to just the getter/setters for [Bindable]. Everything else
is converted to data structures so the framework can interpret the data
structures. The reason is mostly practical. It is scary for most folks to
change the compiler. Better to put the bug fixing in the framework code
where most folks are more familiar. But also, it means that different
frameworks can do different things with the data, and that allows testing
harnesses to muck with what actually happens which is useful if you want
to slip in mocks or test-only versions of things.
Express components could instantiate beads in the setter. That sounds
like a pattern worth more investigation. Basic components won't because
that would involve extending the model beyond the basic model. A Basic
button doesn't even have a model, it doesn't have text or image
properties, or a disabled property. A Basic TextButton adds on a
text/html property. And you plug in the DisableBead without adding to the
model. The Express Button aggregates all of those things and probably
more.
In the end, all of this PAYG and beads and composition comes back to DRY.
We encapsulate small chunks of useful code in beads so nobody else has to
write and debug it. We compose it into heavier aggregations in various
ways: as a strand full of beads so individual beads can be replaced, and
as "inlined" heavy components so you don't have to waste time with all of
these little objects if you know you are going to use all of them most of
the time.
One final thought: I think of large hardware stores. You go to the tool
area and the number of screwdrivers or drills is overwhelming. They are
all slightly different, optimized for some particular scenario. The same
will be true for FlexJS and beads. But the cool thing about software is
that it will have the best "return policy". Grab a bead, try it, toss it
if it doesn't work, check the reviews for what one to try next. Most of
us manage to choose a screwdriver or drill that makes us happy. We will
be able to choose beads as well, but we will need a good online
catalog/store for beads. I hope to see us build one with FlexJS of course.
My 2 cents,
-Alex
On 2/21/17, 5:03 PM, "Guild, Jason A (DFG)" <jason.gu...@alaska.gov> wrote:
>THIS.
>
>As an outsider looking in who also doesn't have much experience with
>FlexJS, I see the approach outlined below to be the best compromise
>between the "FlexJS the API" and PAYG for efficiency.
>
>I know it's just a step on the way, and I am positive that Express will
>be a big help, but I've been alarmed at the number of special-purpose
>beads and tags which have been proposed and implemented to get stuff
>done in a way that was what made Flex so productive in the first place.
>The developer is supposed to browse all of them and know which ones to
>compose together to get the basics?
>
>The approach given below effectively treats PAYG as a course-grained
>optimization pass.
>If the compiler detects that some feature is used and then hooks up the
>appropriate bead automatically then the developer just has to use the
>API and gets PAYG out-of-the-box. If the developer doesn't use a feature
>then the compiler doesn't generate code to set it up.
>
>Powerful concept.
>Jason
>
>
>On 2/21/2017 6:11, Dev LFM wrote:
>> I did not tried yet FlesJS, but I'm listening every post. I think those
>> beads should be added automatically and internally only if needed, ex:
>>
>> if some component have a binding tag like visible="{model.show}", this
>> would automatically add 2 beads, the binding bead and the
>>visibilitybead.
>> What I mean is that every component could be PAYG in the way that are
>>the
>> very basic in the beginning, but as the dev requires functionalities, it
>> should add them automatically. In the cases that the dev wants custom
>> beads, then it must overrides the method that set those beads.
>>
>> Maybe I'm missing some point..
>>
>> 2017-02-21 14:59 GMT+00:00 yishayw <yishayj...@hotmail.com>:
>>
>>> I agree. If you think this bead will be used very often you can create
>>>a
>>> subclass that bakes it in. ImageButton in Express is probably a good
>>> example, though I would use StrandUtils to save some code lines.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://apache-flex-
>>> development.2333347.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
>>> Problem-tp59595p59712.html
>>> Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>>>
>
