I did think of the variable issues. Using instance variables does not generally
strike me as problematic. (unless there’s a lot of them)
I did find some interesting articles on inlining vs function calling. Here’s
one.[1]
Too many super calls might be bad because “call” can be expensive.
Yes.
You're welcome to try different approaches to sharing code in the base
classes. Often, though, loops over children need to be inlined not only
for performance reasons (to cut out one function call in the inner loop),
but also for information sharing reasons (local variables accumulating
values wou
Here’s a dilema I ran into this morning:
The OneFlexibleLayout beads have some code which look like this:
if (!contentView.element.style["align-items"])
contentView.element.style["align-items"] = "center”;
What that does, is check if “align-items” is already set and sets it to center
if not.
not had time to come back and consolidate the various
discussions on this. I still have that intention, just not the time
available right now. Please do not hesitate if you want to kick this off in
the wiki yourself.
On Tue, Jul 25, 2017 at 9:44 AM, Josh Tynjala wrote:
> Okay, so PAYG ca
Okay, so PAYG can't have One True Definition. How you implement PAYG
depends on context.
I wonder if some kind of PAYG pattern cookbook would be helpful? I was
thinking that our situations with PAYG remind me of software design
patterns. Design patterns aren't really defined wit
But if this is framework code convention let's live it as is. I just didn't
> notice that is look like that.
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context:
> http://apache-flex-develop
nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63511.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context:
> http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63509.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63509.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context:
> http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63502.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
x PMC
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-and-dataGroups-tp63496p63502.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Sunday, July 23, 2017 1:11:14 PM
To: dev
Subject: [FlexJS] PAYG and dataGroups
I just ran into a bug in my app as follows:
ListView has the following function:
protected function rollOverIndexChangeHandler(event:Event):void
{
if (lastRollOverIndex != -1)
{
I just ran into a bug in my app as follows:
ListView has the following function:
protected function rollOverIndexChangeHandler(event:Event):void
{
if (lastRollOverIndex != -1)
{
var ir:ISelectableItemRenderer =
dataGroup.getItemRendererForIndex(lastRollOverIndex)
Hi All,
You guys have really interesting conversation related to PAYG. [1] Let's
continue it all here!
[1]
http://apache-flex-development.247.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Add-FileUploaderWithResponseData-td63051.html
Thanks,
Piotr
-
Apache Fle
Hi,
I promised some feedback on Greg's PAYG page. After thinking about it
some more, I'm proposing my take on it below. I know past discussion
tried to break off component set definitions from PAYG, but I think PAYG
is always going to be subjective enough that the goals of the various
described, to exclude
>> development-only code (extra type checking, null checks etc) would
>> definitely also be helpful PAYG-wise from within the framework.
>>
>> The general issue here I think is that using this approach for the
>> framework requires a dev build of
In application development I would normally do this type of thing inside
CONFIG::dev
blocks, or similar, so having the possibility, as described, to exclude
development-only code (extra type checking, null checks etc) would
definitely also be helpful PAYG-wise from within the framework.
The
ity, as described, to exclude
> development-only code (extra type checking, null checks etc) would
> definitely also be helpful PAYG-wise from within the framework.
>
> The general issue here I think is that using this approach for the
> framework requires a dev build of the frame
to add a typecheck to the bytes argument in the BinaryData
>> constructor to throw an error if something other than an ArrayBuffer is
>> provided. We cannot use strict typing to catch this in the compiler,
>> because the argument is different for SWF and JS. Is this a violation of
>> PAYG? It’s sort-of just in case code, but not really because it’s
>> protecting against errors.
>>
>> Thoughts? Other solutions?
>> Harbs
>
was initializing a BinaryData with a
>>> string instead of an ArrayBuffer.
>>>
>>> I would like to add a typecheck to the bytes argument in the BinaryData
>>> constructor to throw an error if something other than an ArrayBuffer is
>>> provided. We cannot use strict typing to catch this in the compiler,
>>> because the argument is different for SWF and JS. Is this a violation of
>>> PAYG? It’s sort-of just in case code, but not really because it’s
>>> protecting against errors.
>>>
>>> Thoughts? Other solutions?
>>> Harbs
>>
>
with a
>string instead of an ArrayBuffer.
>
>I would like to add a typecheck to the bytes argument in the BinaryData
>constructor to throw an error if something other than an ArrayBuffer is
>provided. We cannot use strict typing to catch this in the compiler,
>because the argument is differen
catch this in the compiler, because
the argument is different for SWF and JS. Is this a violation of PAYG? It’s
sort-of just in case code, but not really because it’s protecting against
errors.
Thoughts? Other solutions?
Harbs
the implementation guide, populating it with content from discussions
that have already begun, and then adding more in the future in exactly the
way ( PAYG-ish ) that you describe.
"I'm just not sure we are ready to start paving roads and putting up street
signs."
If by this you
any time.
All the more reason IMO to have some documentation and censuses around concepts
like PAYG. Bus factor is a concern here. [1]
> My managers would much rather that I help one or two customers migrate their
> code than
> write documents so 100 folks can migrate on their own
Hi,
Thanks for that Greg and good to see it started some conversation around this.
Thanks,
Justin
basically, if I’m building a “foo” app, I’d pick the “foo” widget set as the
starting point and that gets me pretty fart along to where I need to be. For
this to be realistic, the Basic set needs to be as modular as possible. Hence
PAYG and extremely modular bead architecture is critical. The thing to
To me it's a bit difficult to digest in its current format. I would prefer to
see a list of design patterns with descriptions of concrete problems and
proposed solutions. This doc could be PAYG in itself. You come across a
problem, solve it with PAYG, add an item in the doc, if the idea
. Hence, UIBase is by default
visible.
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-PAYG-definitions-and-guidance-Please-participate-tp62738p62759.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
I agree with this.
If I had to pick the single-most difficult thing when migrating from Flex to
FlexJS, it would be layout.
The new layout beads are definitely improved over the older ones, but layout is
not always necessarily as intuitive or performant as it might be.
On the one hand, we don’
Great start.
I just made some additions and changes. Hopefully I helped make it clearer and
not the other way around… ;-)
I just want to say, that while PAYG is hard both from a framework development
perspective and from an application development perspective, I firmly believe
that strict
#x27;t think we have
representatives from big enterprise app development teams amongst our
active committers and it could be that the big enterprises that have been
burned by old Flex's size and performance are no longer active Flex
customers. Beads and PAYG is my solution to the problems I saw d
; >
> >It is currently half content, half notes. There is more to harvest from
> >list discussions I think, some topics have progressed further than when I
> >started trying to capture ideas, so please correct any mistakes in the
> >definitions or add topics and questions
e :).
>
>It is currently half content, half notes. There is more to harvest from
>list discussions I think, some topics have progressed further than when I
>started trying to capture ideas, so please correct any mistakes in the
>definitions or add topics and questions that need 'r
in the
definitions or add topics and questions that need 'resolution'/guidance.
I personally would like to see some concrete guidance in the 'How does PAYG
get implemented' section. There were definitely the beginnings of some
healthy discussions around some of the options f
34 matches
Mail list logo
