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.
