Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[piotrz]

Hi,

Personally I prefer this approach even if it is more code.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Beads-and-DRY-was-Re-FlexJS-Removing-PasswordInputBead-has-no-effect-tp62177p62204.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [2/2] git commit: [flex-asjs] [refs/heads/release0.8.0] - fix event types for valuechange. Otherwise Binding would break. Events are global and should be compatible for any given event type

[Alex Harui]

On 6/6/17, 10:27 PM, "Justin Mclean"  wrote:

>Hi,
>
>> I agree that there could be a even smaller bead that doesn't track
>>changes
>> as you move the thumb.  Something to do in the next release, IMO.
>
>Could be or must be? Again just trying to understand why PAYG wasn’t
>followed in this case.

I haven't really thought about it.  I'm still just trying to get a release
out.  User expectations are a factor.  Most folks won't need to remove the
PasswordInputBead.  Do most folks want to track the thumb?
>
>Was this just an accidental design omission that no body picked up on it
>OR is it sometimes OK to have optional feature code in beads?

Probably one of just many bugs we haven't found or fixed yet.  It is
unfortunate we spend all of this energy trying to convince you of the
value of PAYG instead of finding and fixing these bugs.

-Alex

Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[Alex Harui]

I'm not sure there is one right way.  Some features are "cross-cutting",
some build on other features.  The first is done in some languages via
multiple inheritance, which AS doesn't support, so utility functions (I
would like to see our utility classes broken into utility functions) or
even beads with their own strand of child beads is possible.  The second
lends itself to subclassing.

Another question is whether the smallest bead should carry any overhead to
make subclassing easier.  My personal opinion is no, but I haven't done
any research into how much the cost is for the various options.  A
volunteer willing to do this will be greatly appreciated, but it may not
result in a single answer, maybe just data to advise in certain scenarios.

My 2 cents,
-Alex

On 6/6/17, 10:01 PM, "yishayw"  wrote:

>OmPrakash Muppirala wrote
>> Bead A supports feature X
>> Bead B needs to support feature X and Y
>
>Theoretically Bead B could support just feature Y, and the strand would
>choose to add both A and B or just A.
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FBeads-and-DRY-was-Re-FlexJS-Removing
>-PasswordInputBead-has-no-effect-tp62177p62199.html=02%7C01%7C%7C0468
>ec58ff8646d727ca08d4ad645e4e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C
>636324093992333208=RI6FcM6UJwls9fw6MzZZwwk%2FFu5JonjiVlTx%2B5diuow%3
>D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [2/2] git commit: [flex-asjs] [refs/heads/release0.8.0] - fix event types for valuechange. Otherwise Binding would break. Events are global and should be compatible for any given event type

[Justin Mclean]

Hi,

> I agree that there could be a even smaller bead that doesn't track changes
> as you move the thumb.  Something to do in the next release, IMO.

Could be or must be? Again just trying to understand why PAYG wasn’t followed 
in this case.

Was this just an accidental design omission that no body picked up on it OR is 
it sometimes OK to have optional feature code in beads?

Thanks,
Justin

Re: [2/2] git commit: [flex-asjs] [refs/heads/release0.8.0] - fix event types for valuechange. Otherwise Binding would break. Events are global and should be compatible for any given event type

[Alex Harui]

Actually, I was just trying to eliminate an exception so we can ship a
release.

I agree that there could be a even smaller bead that doesn't track changes
as you move the thumb.  Something to do in the next release, IMO.

But I also saw that I hadn't quite implemented the change correctly, so
I've just pushed a better version.

Thanks,
-Alex

On 6/6/17, 5:14 PM, "Justin Mclean"  wrote:

>Hi,
>
>I see you've added code to handle binding / values changes to
>RangeModel.as and RangeModelExtended.as.
>
>Is there any reason the value change code is not in another classes
>called for instance ValueChangeRangeModel? It seem to me that this model
>it trying to do more than one thing i.e. value changes and min/max/step
>changes.
>
>As I user of this I may not be interested minor max changes and only
>interested in value changes so shouldn't that be an optional feature?
>
>I’m just trying to understand why it’s seemingly OK to not follow PAYG
>here.
>
>Thanks,
>Justin

Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[yishayw]

OmPrakash Muppirala wrote
> Bead A supports feature X
> Bead B needs to support feature X and Y

Theoretically Bead B could support just feature Y, and the strand would
choose to add both A and B or just A.




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Beads-and-DRY-was-Re-FlexJS-Removing-PasswordInputBead-has-no-effect-tp62177p62199.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[OmPrakash Muppirala]

On Tue, Jun 6, 2017 at 5:29 PM, Justin Mclean 
wrote:

> Hi,
>
> > In FlexJS we have a preference towards utility classes.
>
> So say we have existing bead A and we want to add some functionality to
> to. In order to use utility classes we would need to modify bead A and pull
> out some of the code into a utility class so bead B can use it.
>
> This will increase the size/runtime cost to existing people using bead A.
> Is this accectable?
>

Yes, there will be a size cost, which is why the inheritance approach is
better than Utils approach for Beads.

*Utils approach:*

Bead A supports feature X
Bead B needs to support feature X and Y

Create a Util class called FeatureXAndY

Bead A calls util:FeatureXAndY (Now Bead A loads code for unnecessary
feature Y)
Bead B calls util:FeatureXAndY

*Inheritance approach:*

Bead A supports feature X
Bead B needs to support feature X and Y

Bead A has code for feature X alone (no extra code)
Bead B extends Bead A and adds code for feature Y (no extra code)
Moreover, no extra util class to maintain.

Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[Justin Mclean]

Hi,

> In FlexJS we have a preference towards utility classes.

So say we have existing bead A and we want to add some functionality to to. In 
order to use utility classes we would need to modify bead A and pull out some 
of the code into a utility class so bead B can use it.

This will increase the size/runtime cost to existing people using bead A. Is 
this accectable?

Thanks,
Justin

Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[Justin Mclean]

Hi,

> This is achieved through composition (the classical OOP paradigm)

The document pointed to yesterday suggests to avoid inheritance and prefer 
composition. Is that just for components and it’s OK to use were needed in 
beads?

Thanks,
Justin.

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

> Actually I will have definitely looked through this early on, but I'd have to 
> say it is quite 'light' on what PAYG actually means beyond the general sense 
> that I had.

I’d go further as say the definition as it is stated there seem to be perhaps 
too wide?

> But I can see that the newly created 'DRY' discussion thread is actually 
> creating the type of content that I think I would have found really helpful 
> in terms of linking a guiding concept to one of its key implementation areas.

+1 to that

> If there's that level of clarity and, ultimately, agreement in terms of 
> definitions and approaches, I expect there will be far less need for threads 
> like this one.

Al +1 to that. We can also point new people to it rather than trying to explain 
the concept(s) again saving everyone time.

Thanks,
Justin

Re: [2/2] git commit: [flex-asjs] [refs/heads/release0.8.0] - fix event types for valuechange. Otherwise Binding would break. Events are global and should be compatible for any given event type

[Justin Mclean]

Hi,

I see you've added code to handle binding / values changes to RangeModel.as and 
RangeModelExtended.as. 

Is there any reason the value change code is not in another classes called for 
instance ValueChangeRangeModel? It seem to me that this model it trying to do 
more than one thing i.e. value changes and min/max/step changes.

As I user of this I may not be interested minor max changes and only interested 
in value changes so shouldn't that be an optional feature?

I’m just trying to understand why it’s seemingly OK to not follow PAYG here.

Thanks,
Justin

Re: git commit: [flex-asjs] [refs/heads/release0.8.0] - Fix for FLEX-35322: NumericStepper layout.

[Justin Mclean]

Hi,

Not 100% sure and I probably not understanding what these methods are doing but 
perhaps the issue is in isHeightSizedToContent / isWidthSizedToContent.

Does the last line of each function look suspect to anyone else?

return (left === undefined || right === undefined);

return (top === undefined || bottom === undefined); 

I would of expected that && be used rather than ||?

Thanks,
Justin

AW: [FlexJS] [Typedefs] [Maven] build issues

[Christofer Dutz]

Nope … don’t have any issues on a Mac.

I wouldn’t say that I am really happy with the patching and all, the way it’s 
done today. We are relying on an external executable. As you might have 
noticed, I don’t like executing Things outside the VM and like to have Things 
inside the Java world and hereby under full control. I wouldn’t bet my life on 
using the git.exe on Windows to do the patching to work identically on Linux 
and Mac for example.

Chris

Von: Greg Dove
Gesendet: Dienstag, 6. Juni 2017 22:45
An: dev@flex.apache.org
Betreff: [FlexJS] [Typedefs] [Maven] build issues

I have had a few issues with maven build of typedefs (in develop) over recent 
times.

I think others may have experienced this also, at least I have seen similar 
things mentioned previously.

For me this seems to be related to patches being applied when the content that 
is being downloaded is already patched (I *think*, based on eyeballing the 
patch and the download js content).

In the past I had this with svg.js and today I had it happen with google maps.
I hand edited  src/main/patch/js.patch to remove the already patched parts for 
svg.js

and today I simply removed the patch part of the pom.xml inside googlemaps 
subdir to get it to build.

I have not committed any of this because I have no knowledge or confidence in 
terms of what the correct approach should be here.

ant build seems to not have an issue with applying the patch content that 
(apparently) is no longer needed.

I am on windows if that possibly makes any difference to the way git apples 
patches.

Chris, or others, are you ever seeing the above issue in the dev maven build 
for typedefs?

[FlexJS] [Typedefs] [Maven] build issues

[Greg Dove]

I have had a few issues with maven build of typedefs (in develop) over recent 
times.

I think others may have experienced this also, at least I have seen similar 
things mentioned previously.

For me this seems to be related to patches being applied when the content that 
is being downloaded is already patched (I *think*, based on eyeballing the 
patch and the download js content). 

In the past I had this with svg.js and today I had it happen with google maps. 
I hand edited  src/main/patch/js.patch to remove the already patched parts for 
svg.js 

and today I simply removed the patch part of the pom.xml inside googlemaps 
subdir to get it to build.

I have not committed any of this because I have no knowledge or confidence in 
terms of what the correct approach should be here.

ant build seems to not have an issue with applying the patch content that 
(apparently) is no longer needed.

I am on windows if that possibly makes any difference to the way git apples 
patches.

Chris, or others, are you ever seeing the above issue in the dev maven build 
for typedefs?

Re: [FlexJS] Removing PasswordInputBead has no effect

[Harbs]

That would be great.

Harbs

> On Jun 6, 2017, at 10:24 PM, Greg Dove  wrote:
> 
> If no-one else volunteers to wiki-fy the contents of the new thread at its 
> conclusion, I will give it a shot over the coming weekend.

Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[Harbs]

There’s actually two ways of adhering to DRY:
1. Subclassing
2. Utility classes.

In FlexJS we have a preference towards utility classes. (and I’d like to see 
even more) Besides very often doing a better job than subclasses in terms of 
avoiding code-repeat, it’s also more geared towards functional programming 
which is a good thing. It allows for easier testing and the like. Lots of small 
utility classes is also much more modular.

So, utility classes solves PAYG, DRY and improved testability. An all around 
win…

As far as beads go vis a vis subclassing, I’d say it depends:
1. The the vast majority of the functionality could be in utility classes, then 
I’d go for two separate classes.
2. If two versions of the same bead-type are unlikely to be used in the same 
app, I’d avoid subclassing as well.
3. If it’s likely to have both versions of the beads in use and utility classes 
are impractical, I’d lean towards subclassing.

My $0.02
Harbs

> On Jun 6, 2017, at 6:52 PM, OmPrakash Muppirala  wrote:
> 
> In an attempt to simplify the pattern, can we say:
> 
> Strands = components
> Beads = functionalities
> 
> All components dont need all functionalities.  We add functionalities to
> components on a Pay As You Go (PAYG) basis.
> 
> This is achieved through composition (the classical OOP paradigm)
> 
> That is, a Strand is composed of several Beads.  Beads are added to Strands
> only when necessary.
> 
> That leaves us with how we build the Beads themselves.  I suggest we
> encourage  inheritance for Beads so as to follow the Dont Repeat Yourself
> (DRY) principle.
> 
> Thanks,
> Om
> 
> 
> On Jun 6, 2017 8:03 AM, "Alex Harui"  wrote:
> 
> I agree we have to be concerned about DRY.  Research into optimal patterns
> for creating common flavors of beads would be very helpful.  The compiler
> might be able to help as well.
> 
> -Alex
> 
> On 6/6/17, 6:52 AM, "Josh Tynjala"  wrote:
> 
>> The way that beads work means that we will frequently "violate" DRY, as I
>> understand it. FlexJS is designed to have multiple beads that implement
>> the
>> same thing in different ways. The simplest bead will be designed to be
>> never removed and it probably won't include any properties to configure
>> its
>> behavior. A more complex bead might include some of the same code from the
>> simplest bead, but it will also be designed to be removed, but still not
>> configured. An even more complex bead will include all three (the core
>> feature, removal, and properties to configure). There might even be a
>> fourth one that can't be removed, but has properties to configure. Going
>> even further, there might even be variations with different subsets of
>> properties that can be configured.
>> 
>> Ideally, we'd find a way to reuse some of the code from the simpler beads.
>> It might be possible to subclass them, for instance. However, unless the
>> simplest beads are designed for it, reusing their code may not be
>> possible.
>> In fact, designing them in a way that they can be extended may violate
>> PAYG
>> instead because it may require adding code that isn't always needed. In
>> that case, there's no option except to repeat some code.
>> 
>> - Josh
>> 
>> On Tue, Jun 6, 2017 at 12:02 AM, Justin Mclean 
>> wrote:
>> 
>>> Hi,
>>> 
 Unless something is functionality that you would (virtually) always
>>> need, it’s a separate bead.
>>> 
>>> So for CCS we have border, does everyone need borders? Why do we only a
>>> sub set of the font attributes included? Some people are not going to
>>> use
>>> all of them or in fact any of them and some other may need other
>>> properties
>>> so why are they not seperate?  Not that I think these should be removed
>>> into seperate parts. The issue is just about every feature you can name
>>> is
>>> going to optional to someone. So I think we near a clearer definition of
>>> what PAYG is.
>>> 
>>> Another example why for instance was flexGrow and flexShrink added in to
>>> the CSS code? Shouldn't they be implemented in line with the PAYG
>>> principal
>>> in another class? And there are numerous other examples of this. I feel
>>> that PAYG is not being applied consistently and seems selective on who
>>> is
>>> making the contribution.
>>> 
 PAYG is already well understood
>>> 
>>> IMO it has not been clearly defined. Alex has described in various ways
>>> as
>>> it size / runtime cost only to move to goal posts. I for one would like
>>> a
>>> clearer definition of it.
>>> 
 All functionality should be implemented as beads when practical. Beads
>>> should be as modular as possible with the smallest possible functional
>>> set.
>>> 
>>> What about the cost of violating DRY or the single responsibility
>>> principal which two beads do similar things? Is it really OK to add
>>> technical debt / penalise users of a new feature when it would be less
>>> cost
>>> modifying/improving an 

Re: [FlexJS] Removing PasswordInputBead has no effect

[Greg Dove]

Alex, and Harbs,

Thanks for pointing that out. Actually I will have defifintely looked through 
this early on, but I'd have to say it is quite 'light' on what PAYG actually 
means beyond the general sense that I had. It does have some more detail about 
beads which is great and I could have benefited from revisiting that in recent 
months which I did not do. 

But I can see that the newly created 'DRY' discussion thread is actually 
creating the type of content that I think I would have found really helpful in 
terms of linking a guiding concept to one of its key implementation areas. 

Creating this type of documentation is *hard*. Not just because creating the 
content itself is a lot of work, But also because it is not (usually I think) 
something that a developer wants to do, especially when volunteering their 
time. "I'd much rather be coding". So thanks Alex for what you already created 
there.
However, I think the contents of the new thread look really good as something 
that could be used as a resource to define bead variation in terms of PAYG 
adherence, as an implementation guide, and I do think we really need this.

If there's that level of clarity and, ultimately, agreement in terms of 
definitions and approaches, I expect there will be far less need for threads 
like this one.

If no-one else volunteers to wiki-fy the contents of the new thread at its 
conclusion, I will give it a shot over the coming weekend.



On 2017-06-06 18:55 (+1200), Alex Harui  wrote: 
> This was first published in 2012.
> 
> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype
> 
> PAYG and avoiding just-in-case code is mentioned in that document.  As are
> Beads.
> 
> Thanks,
> -Alex
> 
> On 6/5/17, 11:33 PM, "Greg Dove"  wrote:
> 
> >Harbs, a quick comment from the sidelines on: "PAYG is already well
> >understood"
> >
> >I don't really think that is the case, at least it has not been for me. I
> >had a more general notion of PAYG that was nothing to do with beads at
> >all,
> >and was limited to guesswork/my own interpretation of it at the beginning
> >because there was no clear definition.
> >
> >Unless this is documented somewhere then I believe it is actually a
> >barrier
> >(of understanding) for people getting involved. If there's already a
> >difficulty with 'thinking this way' and 'acting this way' as you indicated
> >when you had started and had understood it, then it seems important that
> >it
> >should also be easily understood in the first place in order to make
> >things
> >easier for people wanting to participate.
> >
> >As with a lot of things, once you 'know' it you can tend to take if for
> >granted that everyone else does too. But I think you already hinted at
> >that
> >with what you said...
> >
> >I am of the opinion that 'vision', 'mission', 'goals' and even
> >'architecture' etc don't really exist in a form that is useful for shared
> >understanding unless they are documented in some way. And no, 'it's
> >obvious
> >from the source code' is not what I mean :).
> >They are not considered to do so in many other scenarios, in any case, and
> >I can't understand why it would be different in an open source project,
> >although I definitely have not spent time comparing projects to find out
> >what others do here.
> >
> >
> >On Tue, Jun 6, 2017 at 5:21 PM, Harbs  wrote:
> >
> >> We’ve all already been implementing things as Alex states. He
> >>architected
> >> the framework and it’s a good architecture. No need to change things. We
> >> need consistent architecture. We can’t have a free-for-all...
> >>
> >> Percentage of code really has nothing to do with it. Unless something is
> >> functionality that you would (virtually) always need, it’s a separate
> >>bead.
> >> That’s the way the whole SDK is implemented. If there are cases where
> >>it’s
> >> not, it’s a bug and should be fixed. Removal of password functionality
> >>is
> >> NOT usually required for password beads.
> >>
> >> PAYG is already well understood: All functionality should be implemented
> >> as beads when practical. Beads should be as modular as possible with the
> >> smallest possible functional set.
> >>
> >> That’s pretty much it. It’s difficult to make the mental switch to
> >>working
> >> this way. I had similar difficulty when I started implementing things
> >>for
> >> FlexJS. It takes some getting used to, but it’s a very good design.
> >>
> >> Harbs
> >>
> >> > On Jun 6, 2017, at 1:16 AM, Justin Mclean 
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> >> If you have a different vision, you can execute that vision in
> >>another
> >> >> component set or fork FlexJS entirely.  Please do not impose your
> >>vision
> >> >> on my vision.
> >> >
> >> > Since when is this your project Alex or that the project has to only
> >> include your vision? That is not the Apache way.
> >> >
> >> > I would prefer 

Re: Finding tools in the toolbox

[Alex Harui]

I'm not sure what is possible in Flash Builder.  I honestly don't use
code-hinting in FB because I know the APIs pretty well.  If FB with the
regular Flex SDK can offer allowed values for properties, then it should
be possible to offer allowed values for the bead property, although I
think that is done via Metadata and thus won't offer some third-party
offering we didn't know about at framework compile time.

Similarly, if FB already offers refactor via replace, it also probably
relies Metadata and using the same metadata tags on framework classes
should work.

I am hopeful that Josh's VSCode support and other folks who are supporting
FlexJS IDEs will offer more dynamic and powerful support for this kind of
code-hinting.

In FB, if you package DITA files in the SWCs, FB will offer ASDoc in its
code hinting.  I have not had time to see how good the DITA output is that
Christofer Dutz worked on and try to package it in the SWCs.  Maybe a
volunteer can help with that.

HTH,
-Alex

On 6/6/17, 11:36 AM, "Harbs"  wrote:

>Here’s what I’m after:
>1. In mxml, I’d like to markup  and then be given a list of valid
>beads for the current component. What’s the easiest way for tooling to
>get such a list?
>2. With a bead selected, I’d like tooling to allow refactor and give a
>list of beads which can replace the current one with alternate
>functionality. (i.e. different layout, different scrolling behavior,
>different skinning behavior, etc.) It should only present the ones which
>are deemed a “replacement”. Extra credit for docs which describe what the
>bead does.
>
>Harbs
>
>> On Jun 6, 2017, at 8:20 PM, Alex Harui  wrote:
>> 
>> You are welcome to add a new tag.  Could be something like
>> 
>>  @workswith classOrInterface
>> 
>> Or maybe @knownstrands.
>> 
>> I'm not sure what you visualize for "display hierarchy" and "code
>> hinting".  Fundamentally, we have raw data in .json files and you can
>> write code to process and visualize that data.
>> 
>> I would prefer that folks hold off on adding new tags until after we get
>> the release out and merge the release branch back to develop.
>>Otherwise,
>> I think it will increase the likelihood of merge conflicts.
>> 
>> -Alex
>> 
>> On 6/6/17, 10:01 AM, "Harbs" >> wrote:
>> 
>>> It seems like there should be a mechanism to add arbitrary tags that
>>> include references to acceptable components. Maybe use interfaces to
>>> indicate swap-ability?
>>> 
>>> What format would be best for tooling to display hierarchy and code
>>> hinting? Should there be a manifest file, or is the ASDoc enough for
>>>that?
>>> 
 On Jun 6, 2017, at 7:51 PM, Alex Harui 
wrote:
 
 View beads have @viewbead ASDoc tag
 Top-level components have @toplevel ASDoc tag.
 
 All tags are output to tags.json and the ASDoc example could implement
 any
 sort of filtering based on those tags.  New tags I think can be added
by
 just adding them to the ASDoc and maybe telling the compiler to hide
it
 from Google Closure.
 
 That's why I see the need for something that is more of an
"application"
 for our documentation.  The app can compute relationships based on
data.
 Volunteers are encouraged to improve this capability for our ASDoc.
We
 also probably need to solve search engine interfaces for the app as
 well.
 
 BTW, I got the ASDoc in the CI server to work again.  Here are links
to
 the SWF version [1] and JS version[2].
 
 -Alex
 
 [1] 
 
 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachef
le 

 xbuild.cloudapp.net
%3A8080%2Fjob%2FF
lexJS_ASDoc_Example%2FlastSucce=
 
02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c
17
 
8decee1%7C0%7C0%7C636323652817901308=s8fFgxBrse1R0EYwAuEQmDD9QSQF
kw
 lDDmQFoc9dNWU%3D=0
 ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
 
 [2] 
 
 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachef
le 

 xbuild.cloudapp.net
%3A8080%2Fjob%2FF
lexJS_ASDoc_Example%2FlastSucce=
 

Re: Finding tools in the toolbox

[Harbs]

Here’s what I’m after:
1. In mxml, I’d like to markup  and then be given a list of valid beads 
for the current component. What’s the easiest way for tooling to get such a 
list?
2. With a bead selected, I’d like tooling to allow refactor and give a list of 
beads which can replace the current one with alternate functionality. (i.e. 
different layout, different scrolling behavior, different skinning behavior, 
etc.) It should only present the ones which are deemed a “replacement”. Extra 
credit for docs which describe what the bead does.

Harbs

> On Jun 6, 2017, at 8:20 PM, Alex Harui  wrote:
> 
> You are welcome to add a new tag.  Could be something like
> 
>  @workswith classOrInterface
> 
> Or maybe @knownstrands.
> 
> I'm not sure what you visualize for "display hierarchy" and "code
> hinting".  Fundamentally, we have raw data in .json files and you can
> write code to process and visualize that data.
> 
> I would prefer that folks hold off on adding new tags until after we get
> the release out and merge the release branch back to develop.  Otherwise,
> I think it will increase the likelihood of merge conflicts.
> 
> -Alex
> 
> On 6/6/17, 10:01 AM, "Harbs"  > wrote:
> 
>> It seems like there should be a mechanism to add arbitrary tags that
>> include references to acceptable components. Maybe use interfaces to
>> indicate swap-ability?
>> 
>> What format would be best for tooling to display hierarchy and code
>> hinting? Should there be a manifest file, or is the ASDoc enough for that?
>> 
>>> On Jun 6, 2017, at 7:51 PM, Alex Harui  wrote:
>>> 
>>> View beads have @viewbead ASDoc tag
>>> Top-level components have @toplevel ASDoc tag.
>>> 
>>> All tags are output to tags.json and the ASDoc example could implement
>>> any
>>> sort of filtering based on those tags.  New tags I think can be added by
>>> just adding them to the ASDoc and maybe telling the compiler to hide it
>>> from Google Closure.
>>> 
>>> That's why I see the need for something that is more of an "application"
>>> for our documentation.  The app can compute relationships based on data.
>>> Volunteers are encouraged to improve this capability for our ASDoc.  We
>>> also probably need to solve search engine interfaces for the app as
>>> well.
>>> 
>>> BTW, I got the ASDoc in the CI server to work again.  Here are links to
>>> the SWF version [1] and JS version[2].
>>> 
>>> -Alex
>>> 
>>> [1] 
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle 
>>> 
>>> xbuild.cloudapp.net 
>>> %3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSucce=
>>> 02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c17
>>> 8decee1%7C0%7C0%7C636323652817901308=s8fFgxBrse1R0EYwAuEQmDD9QSQFkw
>>> lDDmQFoc9dNWU%3D=0
>>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
>>> 
>>> [2] 
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle 
>>> 
>>> xbuild.cloudapp.net 
>>> %3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSucce=
>>> 02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c17
>>> 8decee1%7C0%7C0%7C636323652817901308=s8fFgxBrse1R0EYwAuEQmDD9QSQFkw
>>> lDDmQFoc9dNWU%3D=0
>>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html
>>> 
>>> On 6/6/17, 8:46 AM, "Harbs"  wrote:
>>> 
 What do the annotations look like?
 
 Maybe there should be some kind of manifest that documents beads and
 their relationships?
 
 
> On Jun 6, 2017, at 5:46 PM, Alex Harui 
> wrote:
> 
> Definitely needs more.
> 
> In the ASDoc example, there is a checkbox to see just view beads.  I
> have
> added ASDoc annotations to the view beads so they show up when that
> filter
> is on.  I'm sure view beads may have been added since I first did
> that,
> and maybe the annotation accidentally got copied into new beads that
> aren't view beads, but that's my idea for how to find tools in the
> toolbox.
> 
> If folks like it, please add more annotations and propose and
> implement
> how to generalize the filtering so it isn't 40 checkboxes some day.
> 
> BTW, the ASDoc example on the CI server is broken.  That'll be my
> stop-ship release bug for today.  Until then, you can build the
> example
> locally and see how the checkbox works.
> 
> Thanks,
> -Alex
> 
> On 6/5/17, 10:58 PM, "Harbs"  wrote:
> 
>> One of the most difficult part of dealing with FlexJS and beads is
>> knowing what beads are available and what beads are interchangeable.
>> 
>> I think we need 

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[piotrz]

Looking forward to it! :)



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/LAST-CALL-Release-FlexJS-FalconJX-0-8-0-tp61275p62184.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Alex Harui]

OK, Maven is building, NumericStepper seems to be working and ASDoc is
working.  Sounds like we are good to go.  I will prepare an RC tonight.

Thanks everyone!
-Alex

On 6/6/17, 12:41 AM, "piotrz"  wrote:

>Yep. It should. I did fix yesterday and monitoring it all the time. :) I
>would also be against if Maven build is not working. :)
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FLAST-CALL-Release-FlexJS-FalconJX-0-
>8-0-tp61275p62154.html=02%7C01%7C%7C9cbf622963d04634b1fc08d4acb19933%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636323326160158790=Beje
>Wa1PCpVqOpdBQFOy%2B5Zxwhbx2ggDN9YwkRkc%2FjA%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Finding tools in the toolbox

[Alex Harui]

You are welcome to add a new tag.  Could be something like

  @workswith classOrInterface

Or maybe @knownstrands.

I'm not sure what you visualize for "display hierarchy" and "code
hinting".  Fundamentally, we have raw data in .json files and you can
write code to process and visualize that data.

I would prefer that folks hold off on adding new tags until after we get
the release out and merge the release branch back to develop.  Otherwise,
I think it will increase the likelihood of merge conflicts.

-Alex

On 6/6/17, 10:01 AM, "Harbs"  wrote:

>It seems like there should be a mechanism to add arbitrary tags that
>include references to acceptable components. Maybe use interfaces to
>indicate swap-ability?
>
>What format would be best for tooling to display hierarchy and code
>hinting? Should there be a manifest file, or is the ASDoc enough for that?
>
>> On Jun 6, 2017, at 7:51 PM, Alex Harui  wrote:
>> 
>> View beads have @viewbead ASDoc tag
>> Top-level components have @toplevel ASDoc tag.
>> 
>> All tags are output to tags.json and the ASDoc example could implement
>>any
>> sort of filtering based on those tags.  New tags I think can be added by
>> just adding them to the ASDoc and maybe telling the compiler to hide it
>> from Google Closure.
>> 
>> That's why I see the need for something that is more of an "application"
>> for our documentation.  The app can compute relationships based on data.
>> Volunteers are encouraged to improve this capability for our ASDoc.  We
>> also probably need to solve search engine interfaces for the app as
>>well.
>> 
>> BTW, I got the ASDoc in the CI server to work again.  Here are links to
>> the SWF version [1] and JS version[2].
>> 
>> -Alex
>> 
>> [1] 
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle
>>xbuild.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSucce=
>>02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c17
>>8decee1%7C0%7C0%7C636323652817901308=s8fFgxBrse1R0EYwAuEQmDD9QSQFkw
>>lDDmQFoc9dNWU%3D=0
>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
>> 
>> [2] 
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachefle
>>xbuild.cloudapp.net%3A8080%2Fjob%2FFlexJS_ASDoc_Example%2FlastSucce=
>>02%7C01%7C%7C46e612dfe85445e0789308d4acfda6ad%7Cfa7b1b5a7b34438794aed2c17
>>8decee1%7C0%7C0%7C636323652817901308=s8fFgxBrse1R0EYwAuEQmDD9QSQFkw
>>lDDmQFoc9dNWU%3D=0
>> ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html
>> 
>> On 6/6/17, 8:46 AM, "Harbs"  wrote:
>> 
>>> What do the annotations look like?
>>> 
>>> Maybe there should be some kind of manifest that documents beads and
>>> their relationships?
>>> 
>>> 
 On Jun 6, 2017, at 5:46 PM, Alex Harui 
wrote:
 
 Definitely needs more.
 
 In the ASDoc example, there is a checkbox to see just view beads.  I
 have
 added ASDoc annotations to the view beads so they show up when that
 filter
 is on.  I'm sure view beads may have been added since I first did
that,
 and maybe the annotation accidentally got copied into new beads that
 aren't view beads, but that's my idea for how to find tools in the
 toolbox.
 
 If folks like it, please add more annotations and propose and
implement
 how to generalize the filtering so it isn't 40 checkboxes some day.
 
 BTW, the ASDoc example on the CI server is broken.  That'll be my
 stop-ship release bug for today.  Until then, you can build the
example
 locally and see how the checkbox works.
 
 Thanks,
 -Alex
 
 On 6/5/17, 10:58 PM, "Harbs"  wrote:
 
> One of the most difficult part of dealing with FlexJS and beads is
> knowing what beads are available and what beads are interchangeable.
> 
> I think we need a system to programmatically be able to look up bead
> and
> strand relationships. This could be used by documentation as well as
> tooling to give hints as to what beads to use.
> 
> I think there’s been some discussion already on this, but I’m kind of
> fuzzy and it probably needs some more.
> 
> Harbs
 
>>> 
>> 
>

Re: Finding tools in the toolbox

[Harbs]

It seems like there should be a mechanism to add arbitrary tags that include 
references to acceptable components. Maybe use interfaces to indicate 
swap-ability?

What format would be best for tooling to display hierarchy and code hinting? 
Should there be a manifest file, or is the ASDoc enough for that?

> On Jun 6, 2017, at 7:51 PM, Alex Harui  wrote:
> 
> View beads have @viewbead ASDoc tag
> Top-level components have @toplevel ASDoc tag.
> 
> All tags are output to tags.json and the ASDoc example could implement any
> sort of filtering based on those tags.  New tags I think can be added by
> just adding them to the ASDoc and maybe telling the compiler to hide it
> from Google Closure.
> 
> That's why I see the need for something that is more of an "application"
> for our documentation.  The app can compute relationships based on data.
> Volunteers are encouraged to improve this capability for our ASDoc.  We
> also probably need to solve search engine interfaces for the app as well.
> 
> BTW, I got the ASDoc in the CI server to work again.  Here are links to
> the SWF version [1] and JS version[2].
> 
> -Alex
> 
> [1] 
> http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSucce
> ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html
> 
> [2] 
> http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSucce
> ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html
> 
> On 6/6/17, 8:46 AM, "Harbs"  wrote:
> 
>> What do the annotations look like?
>> 
>> Maybe there should be some kind of manifest that documents beads and
>> their relationships?
>> 
>> 
>>> On Jun 6, 2017, at 5:46 PM, Alex Harui  wrote:
>>> 
>>> Definitely needs more.
>>> 
>>> In the ASDoc example, there is a checkbox to see just view beads.  I
>>> have
>>> added ASDoc annotations to the view beads so they show up when that
>>> filter
>>> is on.  I'm sure view beads may have been added since I first did that,
>>> and maybe the annotation accidentally got copied into new beads that
>>> aren't view beads, but that's my idea for how to find tools in the
>>> toolbox.
>>> 
>>> If folks like it, please add more annotations and propose and implement
>>> how to generalize the filtering so it isn't 40 checkboxes some day.
>>> 
>>> BTW, the ASDoc example on the CI server is broken.  That'll be my
>>> stop-ship release bug for today.  Until then, you can build the example
>>> locally and see how the checkbox works.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/5/17, 10:58 PM, "Harbs"  wrote:
>>> 
 One of the most difficult part of dealing with FlexJS and beads is
 knowing what beads are available and what beads are interchangeable.
 
 I think we need a system to programmatically be able to look up bead
 and
 strand relationships. This could be used by documentation as well as
 tooling to give hints as to what beads to use.
 
 I think there’s been some discussion already on this, but I’m kind of
 fuzzy and it probably needs some more.
 
 Harbs
>>> 
>> 
> 

Re: Finding tools in the toolbox

[Alex Harui]

View beads have @viewbead ASDoc tag
Top-level components have @toplevel ASDoc tag.

All tags are output to tags.json and the ASDoc example could implement any
sort of filtering based on those tags.  New tags I think can be added by
just adding them to the ASDoc and maybe telling the compiler to hide it
from Google Closure.

That's why I see the need for something that is more of an "application"
for our documentation.  The app can compute relationships based on data.
Volunteers are encouraged to improve this capability for our ASDoc.  We
also probably need to solve search engine interfaces for the app as well.

BTW, I got the ASDoc in the CI server to work again.  Here are links to
the SWF version [1] and JS version[2].

-Alex

[1] 
http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSucce
ssfulBuild/artifact/examples/flexjs/ASDoc/bin-debug/ASDoc.html

[2] 
http://apacheflexbuild.cloudapp.net:8080/job/FlexJS_ASDoc_Example/lastSucce
ssfulBuild/artifact/examples/flexjs/ASDoc/bin/js-debug/index.html

On 6/6/17, 8:46 AM, "Harbs"  wrote:

>What do the annotations look like?
>
>Maybe there should be some kind of manifest that documents beads and
>their relationships?
>
>
>> On Jun 6, 2017, at 5:46 PM, Alex Harui  wrote:
>> 
>> Definitely needs more.
>> 
>> In the ASDoc example, there is a checkbox to see just view beads.  I
>>have
>> added ASDoc annotations to the view beads so they show up when that
>>filter
>> is on.  I'm sure view beads may have been added since I first did that,
>> and maybe the annotation accidentally got copied into new beads that
>> aren't view beads, but that's my idea for how to find tools in the
>>toolbox.
>> 
>> If folks like it, please add more annotations and propose and implement
>> how to generalize the filtering so it isn't 40 checkboxes some day.
>> 
>> BTW, the ASDoc example on the CI server is broken.  That'll be my
>> stop-ship release bug for today.  Until then, you can build the example
>> locally and see how the checkbox works.
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/5/17, 10:58 PM, "Harbs"  wrote:
>> 
>>> One of the most difficult part of dealing with FlexJS and beads is
>>> knowing what beads are available and what beads are interchangeable.
>>> 
>>> I think we need a system to programmatically be able to look up bead
>>>and
>>> strand relationships. This could be used by documentation as well as
>>> tooling to give hints as to what beads to use.
>>> 
>>> I think there’s been some discussion already on this, but I’m kind of
>>> fuzzy and it probably needs some more.
>>> 
>>> Harbs
>> 
>

Re: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[OmPrakash Muppirala]

In an attempt to simplify the pattern, can we say:

Strands = components
Beads = functionalities

All components dont need all functionalities.  We add functionalities to
components on a Pay As You Go (PAYG) basis.

This is achieved through composition (the classical OOP paradigm)

That is, a Strand is composed of several Beads.  Beads are added to Strands
only when necessary.

That leaves us with how we build the Beads themselves.  I suggest we
encourage  inheritance for Beads so as to follow the Dont Repeat Yourself
(DRY) principle.

Thanks,
Om


On Jun 6, 2017 8:03 AM, "Alex Harui"  wrote:

I agree we have to be concerned about DRY.  Research into optimal patterns
for creating common flavors of beads would be very helpful.  The compiler
might be able to help as well.

-Alex

On 6/6/17, 6:52 AM, "Josh Tynjala"  wrote:

>The way that beads work means that we will frequently "violate" DRY, as I
>understand it. FlexJS is designed to have multiple beads that implement
>the
>same thing in different ways. The simplest bead will be designed to be
>never removed and it probably won't include any properties to configure
>its
>behavior. A more complex bead might include some of the same code from the
>simplest bead, but it will also be designed to be removed, but still not
>configured. An even more complex bead will include all three (the core
>feature, removal, and properties to configure). There might even be a
>fourth one that can't be removed, but has properties to configure. Going
>even further, there might even be variations with different subsets of
>properties that can be configured.
>
>Ideally, we'd find a way to reuse some of the code from the simpler beads.
>It might be possible to subclass them, for instance. However, unless the
>simplest beads are designed for it, reusing their code may not be
>possible.
>In fact, designing them in a way that they can be extended may violate
>PAYG
>instead because it may require adding code that isn't always needed. In
>that case, there's no option except to repeat some code.
>
>- Josh
>
>On Tue, Jun 6, 2017 at 12:02 AM, Justin Mclean 
>wrote:
>
>> Hi,
>>
>> >  Unless something is functionality that you would (virtually) always
>> need, it’s a separate bead.
>>
>> So for CCS we have border, does everyone need borders? Why do we only a
>> sub set of the font attributes included? Some people are not going to
>>use
>> all of them or in fact any of them and some other may need other
>>properties
>> so why are they not seperate?  Not that I think these should be removed
>> into seperate parts. The issue is just about every feature you can name
>>is
>> going to optional to someone. So I think we near a clearer definition of
>> what PAYG is.
>>
>> Another example why for instance was flexGrow and flexShrink added in to
>> the CSS code? Shouldn't they be implemented in line with the PAYG
>>principal
>> in another class? And there are numerous other examples of this. I feel
>> that PAYG is not being applied consistently and seems selective on who
>>is
>> making the contribution.
>>
>> > PAYG is already well understood
>>
>> IMO it has not been clearly defined. Alex has described in various ways
>>as
>> it size / runtime cost only to move to goal posts. I for one would like
>>a
>> clearer definition of it.
>>
>> > All functionality should be implemented as beads when practical. Beads
>> should be as modular as possible with the smallest possible functional
>>set.
>>
>> What about the cost of violating DRY or the single responsibility
>> principal which two beads do similar things? Is it really OK to add
>> technical debt / penalise users of a new feature when it would be less
>>cost
>> modifying/improving an existing bead at a much smaller cost? How do you
>> discourage copy paste coding?
>>
>> Thanks,
>> Justin

Re: Finding tools in the toolbox

[Harbs]

What do the annotations look like?

Maybe there should be some kind of manifest that documents beads and their 
relationships?


> On Jun 6, 2017, at 5:46 PM, Alex Harui  wrote:
> 
> Definitely needs more.
> 
> In the ASDoc example, there is a checkbox to see just view beads.  I have
> added ASDoc annotations to the view beads so they show up when that filter
> is on.  I'm sure view beads may have been added since I first did that,
> and maybe the annotation accidentally got copied into new beads that
> aren't view beads, but that's my idea for how to find tools in the toolbox.
> 
> If folks like it, please add more annotations and propose and implement
> how to generalize the filtering so it isn't 40 checkboxes some day.
> 
> BTW, the ASDoc example on the CI server is broken.  That'll be my
> stop-ship release bug for today.  Until then, you can build the example
> locally and see how the checkbox works.
> 
> Thanks,
> -Alex
> 
> On 6/5/17, 10:58 PM, "Harbs"  wrote:
> 
>> One of the most difficult part of dealing with FlexJS and beads is
>> knowing what beads are available and what beads are interchangeable.
>> 
>> I think we need a system to programmatically be able to look up bead and
>> strand relationships. This could be used by documentation as well as
>> tooling to give hints as to what beads to use.
>> 
>> I think there’s been some discussion already on this, but I’m kind of
>> fuzzy and it probably needs some more.
>> 
>> Harbs
> 

Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

[Alex Harui]

I agree we have to be concerned about DRY.  Research into optimal patterns
for creating common flavors of beads would be very helpful.  The compiler
might be able to help as well.

-Alex

On 6/6/17, 6:52 AM, "Josh Tynjala"  wrote:

>The way that beads work means that we will frequently "violate" DRY, as I
>understand it. FlexJS is designed to have multiple beads that implement
>the
>same thing in different ways. The simplest bead will be designed to be
>never removed and it probably won't include any properties to configure
>its
>behavior. A more complex bead might include some of the same code from the
>simplest bead, but it will also be designed to be removed, but still not
>configured. An even more complex bead will include all three (the core
>feature, removal, and properties to configure). There might even be a
>fourth one that can't be removed, but has properties to configure. Going
>even further, there might even be variations with different subsets of
>properties that can be configured.
>
>Ideally, we'd find a way to reuse some of the code from the simpler beads.
>It might be possible to subclass them, for instance. However, unless the
>simplest beads are designed for it, reusing their code may not be
>possible.
>In fact, designing them in a way that they can be extended may violate
>PAYG
>instead because it may require adding code that isn't always needed. In
>that case, there's no option except to repeat some code.
>
>- Josh
>
>On Tue, Jun 6, 2017 at 12:02 AM, Justin Mclean 
>wrote:
>
>> Hi,
>>
>> >  Unless something is functionality that you would (virtually) always
>> need, it’s a separate bead.
>>
>> So for CCS we have border, does everyone need borders? Why do we only a
>> sub set of the font attributes included? Some people are not going to
>>use
>> all of them or in fact any of them and some other may need other
>>properties
>> so why are they not seperate?  Not that I think these should be removed
>> into seperate parts. The issue is just about every feature you can name
>>is
>> going to optional to someone. So I think we near a clearer definition of
>> what PAYG is.
>>
>> Another example why for instance was flexGrow and flexShrink added in to
>> the CSS code? Shouldn't they be implemented in line with the PAYG
>>principal
>> in another class? And there are numerous other examples of this. I feel
>> that PAYG is not being applied consistently and seems selective on who
>>is
>> making the contribution.
>>
>> > PAYG is already well understood
>>
>> IMO it has not been clearly defined. Alex has described in various ways
>>as
>> it size / runtime cost only to move to goal posts. I for one would like
>>a
>> clearer definition of it.
>>
>> > All functionality should be implemented as beads when practical. Beads
>> should be as modular as possible with the smallest possible functional
>>set.
>>
>> What about the cost of violating DRY or the single responsibility
>> principal which two beads do similar things? Is it really OK to add
>> technical debt / penalise users of a new feature when it would be less
>>cost
>> modifying/improving an existing bead at a much smaller cost? How do you
>> discourage copy paste coding?
>>
>> Thanks,
>> Justin

Re: Finding tools in the toolbox

[Alex Harui]

Definitely needs more.

In the ASDoc example, there is a checkbox to see just view beads.  I have
added ASDoc annotations to the view beads so they show up when that filter
is on.  I'm sure view beads may have been added since I first did that,
and maybe the annotation accidentally got copied into new beads that
aren't view beads, but that's my idea for how to find tools in the toolbox.

If folks like it, please add more annotations and propose and implement
how to generalize the filtering so it isn't 40 checkboxes some day.

BTW, the ASDoc example on the CI server is broken.  That'll be my
stop-ship release bug for today.  Until then, you can build the example
locally and see how the checkbox works.

Thanks,
-Alex

On 6/5/17, 10:58 PM, "Harbs"  wrote:

>One of the most difficult part of dealing with FlexJS and beads is
>knowing what beads are available and what beads are interchangeable.
>
>I think we need a system to programmatically be able to look up bead and
>strand relationships. This could be used by documentation as well as
>tooling to give hints as to what beads to use.
>
>I think there’s been some discussion already on this, but I’m kind of
>fuzzy and it probably needs some more.
>
>Harbs

Re: [FlexJS] Layout of NumericStepper is broken

[Peter Ent]

I found the problem: the NumericStepper's sizeChange handler was not being
called when the NS appears in this simpler test case. It is being called
when it is displayed in the FlexJSStore, for example. The more complex app
with nested containers and layouts is setting the right conditions so the
size change handler runs.

If I remove the test and always call the size change handler, both this
simple test and the FlexJSStore work fine. But there are some minor
alignment issues which I can also correct.

I don't want to check in my changes without having Alex think about why
those changes were put in place since there may be consequences of
returning the NS to a more simpler form.

‹peter

On 6/6/17, 3:17 AM, "piotrz"  wrote:

>Peter,
>
>I just raised jira ->
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.ap
>ache.org%2Fjira%2Fbrowse%2FFLEX-35322=02%7C01%7C%7Cafd0984b2a2d4a2643
>d308d4acae46fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63632331191193
>2511=6aA%2FoP%2BRTmEXaHh0aU2pRgufprYkfmGw7tmkipKsFMM%3D=0
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Layout-of-NumericStepper-is-b
>roken-tp62108p62149.html=02%7C01%7C%7Cafd0984b2a2d4a2643d308d4acae46f
>d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636323311911932511=io
>xNCT03PcPjwOIytCr2%2FUjst9mGuqx2b%2BCTLqBJ7Kw%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Removing PasswordInputBead has no effect

[Josh Tynjala]

The way that beads work means that we will frequently "violate" DRY, as I
understand it. FlexJS is designed to have multiple beads that implement the
same thing in different ways. The simplest bead will be designed to be
never removed and it probably won't include any properties to configure its
behavior. A more complex bead might include some of the same code from the
simplest bead, but it will also be designed to be removed, but still not
configured. An even more complex bead will include all three (the core
feature, removal, and properties to configure). There might even be a
fourth one that can't be removed, but has properties to configure. Going
even further, there might even be variations with different subsets of
properties that can be configured.

Ideally, we'd find a way to reuse some of the code from the simpler beads.
It might be possible to subclass them, for instance. However, unless the
simplest beads are designed for it, reusing their code may not be possible.
In fact, designing them in a way that they can be extended may violate PAYG
instead because it may require adding code that isn't always needed. In
that case, there's no option except to repeat some code.

- Josh

On Tue, Jun 6, 2017 at 12:02 AM, Justin Mclean 
wrote:

> Hi,
>
> >  Unless something is functionality that you would (virtually) always
> need, it’s a separate bead.
>
> So for CCS we have border, does everyone need borders? Why do we only a
> sub set of the font attributes included? Some people are not going to use
> all of them or in fact any of them and some other may need other properties
> so why are they not seperate?  Not that I think these should be removed
> into seperate parts. The issue is just about every feature you can name is
> going to optional to someone. So I think we near a clearer definition of
> what PAYG is.
>
> Another example why for instance was flexGrow and flexShrink added in to
> the CSS code? Shouldn't they be implemented in line with the PAYG principal
> in another class? And there are numerous other examples of this. I feel
> that PAYG is not being applied consistently and seems selective on who is
> making the contribution.
>
> > PAYG is already well understood
>
> IMO it has not been clearly defined. Alex has described in various ways as
> it size / runtime cost only to move to goal posts. I for one would like a
> clearer definition of it.
>
> > All functionality should be implemented as beads when practical. Beads
> should be as modular as possible with the smallest possible functional set.
>
> What about the cost of violating DRY or the single responsibility
> principal which two beads do similar things? Is it really OK to add
> technical debt / penalise users of a new feature when it would be less cost
> modifying/improving an existing bead at a much smaller cost? How do you
> discourage copy paste coding?
>
> Thanks,
> Justin

Re: [FlexJS] Layout of NumericStepper is broken

[Peter Ent]

OK, thanks. I'm looking at this now (as soon as my sync of Alex's changes
completes).
‹peter

On 6/6/17, 3:17 AM, "piotrz"  wrote:

>Peter,
>
>I just raised jira ->
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.ap
>ache.org%2Fjira%2Fbrowse%2FFLEX-35322=02%7C01%7C%7Cafd0984b2a2d4a2643
>d308d4acae46fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63632331191193
>2511=6aA%2FoP%2BRTmEXaHh0aU2pRgufprYkfmGw7tmkipKsFMM%3D=0
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Layout-of-NumericStepper-is-b
>roken-tp62108p62149.html=02%7C01%7C%7Cafd0984b2a2d4a2643d308d4acae46f
>d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636323311911932511=io
>xNCT03PcPjwOIytCr2%2FUjst9mGuqx2b%2BCTLqBJ7Kw%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Harbs]

It sounds like a micro-optimization, but it saves some bytes and doesn’t look 
like a functional change, so go knock yourself out… ;-)

> On Jun 6, 2017, at 1:43 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> Just profiled these with a variety of inputs and the first is around 3 times 
> as fast as the second.
> 
> I added a null check to stop the RTE, if the null check is not needed it can 
> be removed from both.
> 
> public function test(str:String):Number {
>var pixels:Number = NaN;
>if (str !== null && str.indexOf('%') === -1)
>pixels = parseFloat(str);
> 
>return pixels;  
> }
> 
> public function test2(str:String):Number {
>var pixels:Number;
>if (str !== null && str.indexOf('%') != -1)
>pixels = NaN;
>else if (str !== null && str.length == 0)
>pixels = NaN;
>else
>pixels = parseFloat(str);
> 
>return pixels;
> }
> 
> Thanks,
> Justin
> 

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[piotrz]

I think it would be great! Let see what Alex thing. 

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-2-4-git-commit-flex-asjs-refs-heads-release0-8-0-looks-like-we-get-empty-string-sometimes-which-cN-tp62159p62168.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Harbs]

True.

else if (strpixels.length == 0)

should probably be:
else if (strpixels === “”)

> On Jun 6, 2017, at 1:01 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Language.as() is not being called (@flexjsignorecoercion is being used).
> 
> And it will still throw an RTE if strpixels is null.
> 
>> if (strpixels !== null && strpixels.indexOf('%') != -1)
> 
> will be false
> 
>> else if (strpixels.length == 0)
> 
> throws RTE
> 
> Thanks,
> Justin

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Harbs]

Changed.

> On Jun 6, 2017, at 1:37 PM, Harbs  wrote:
> 
> True.
> 
> else if (strpixels.length == 0)
> 
> should probably be:
> else if (strpixels === “”)
> 
>> On Jun 6, 2017, at 1:01 PM, Justin Mclean  wrote:
>> 
>> Hi,
>> 
>>> Language.as() is not being called (@flexjsignorecoercion is being used).
>> 
>> And it will still throw an RTE if strpixels is null.
>> 
>>> if (strpixels !== null && strpixels.indexOf('%') != -1)
>> 
>> will be false
>> 
>>> else if (strpixels.length == 0)
>> 
>> throws RTE
>> 
>> Thanks,
>> Justin
> 

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Justin Mclean]

Hi,

Just profiled these with a variety of inputs and the first is around 3 times as 
fast as the second.

I added a null check to stop the RTE, if the null check is not needed it can be 
removed from both.

public function test(str:String):Number {
var pixels:Number = NaN;
if (str !== null && str.indexOf('%') === -1)
pixels = parseFloat(str);

return pixels;  
}

public function test2(str:String):Number {
var pixels:Number;
if (str !== null && str.indexOf('%') != -1)
pixels = NaN;
else if (str !== null && str.length == 0)
pixels = NaN;
else
pixels = parseFloat(str);

return pixels;
}

Thanks,
Justin

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Justin Mclean]

Hi,

> var strpixels:String = element.style.width as String; 
> if (strpixels.indexOf('%') === -1) 
> 
> We may have still RTE ?

Yep it would also RTE if strpixels was null.

So perhaps this instead?
> if (strpixels !== null && strpixels.indexOf('%') === -1) 


Justin

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[piotrz]

I think it would be good to change all those with your proposition. For me
it's cleaner, but with this one from you:

var strpixels:String = element.style.width as String; 
if (strpixels.indexOf('%') === -1) 

We may have still RTE ?

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-2-4-git-commit-flex-asjs-refs-heads-release0-8-0-looks-like-we-get-empty-string-sometimes-which-cN-tp62159p62166.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Justin Mclean]

Hi,

> You propose changing whole this part [1] with yours ? 

Or something similar / along those line that was off the top of my head and had 
not been tested.

Perhaps if null is never passed in then it doesn’t need to be checked for and 
the code may not RTE?

Thanks,
Justin

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[piotrz]

Justin,

You propose changing whole this part [1] with yours ? 

[1] https://paste.apache.org/L1Mq

Just wanted to understand.

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-2-4-git-commit-flex-asjs-refs-heads-release0-8-0-looks-like-we-get-empty-string-sometimes-which-cN-tp62159p62164.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Justin Mclean]

Hi,

> Language.as() is not being called (@flexjsignorecoercion is being used).

And it will still throw an RTE if strpixels is null.

>  if (strpixels !== null && strpixels.indexOf('%') != -1)

will be false

> else if (strpixels.length == 0)

throws RTE

Thanks,
Justin

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Harbs]

Language.as() is not being called (@flexjsignorecoercion is being used).

> On Jun 6, 2017, at 12:50 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> In more detail the issue is that the property is likely to default to 
> undefined and casting that to String in JS like so 
> org.apache.flex.utils.Language.as(undefined, String)) will set the value to 
> null and strpixels.length with throw a RTE. So it’s likely this change in 
> will cause all sort of issues.
> 
> Thanks,
> Justin

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Justin Mclean]

Hi,

In more detail the issue is that the property is likely to default to undefined 
and casting that to String in JS like so 
org.apache.flex.utils.Language.as(undefined, String)) will set the value to 
null and strpixels.length with throw a RTE. So it’s likely this change in will 
cause all sort of issues.

Thanks,
Justin

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Justin Mclean]

Hi,

in fact this code will throw a RTE is width / strpixels is null so you may want 
to reconsider the implementation.

Justin

Re: [2/4] git commit: [flex-asjs] [refs/heads/release0.8.0] - looks like we get '' (empty string) sometimes which coerces to 0. We want it to be NaN

[Justin Mclean]

Hi,

This is probably a simpler / less costly way of doing the same thing:

var pixels:Number = NaN;
var strpixels:String = element.style.width as String;
if (strpixels.indexOf('%') === -1)
pixels = parseFloat(strpixels);

Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[piotrz]

I think because this bead after your changes is doing two things and you can
split responsibility to the other class. - Is it enough reasonable ?

Piotr 



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62158.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

> What’s not clear once you read that doc?


It’s unclear to me why the code I checked in isn’t PAYG as it fits with the 
definition of PAYG in that document.

Thanks,
Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Harbs]

The definition is fine. The fact that it’s 4 years old is irrelevant.

What’s not clear once you read that doc?

Please just revert your changes and make a new bead. There’s no reason to have 
so much discussion on this…

> On Jun 6, 2017, at 11:18 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Imposing your different opinion in others is not the Apache Way.
> 
> How am I’m imposing anything here Alex? It is you that's instating that  just 
> in time code that follows the PAYG principal as documented and that has zero 
> practical overhead is not PAYG.
> 
> From my understanding several people are unclear of what PAYG actually is and 
> there are several differing options on what it is. Perhaps the definition 
> that you pointed to needs to be updated as you said it is 4 years old.
> 
> Wouldn’t it be best to document it so we can all be on the same page?
> 
> Thanks,
> Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

> Imposing your different opinion in others is not the Apache Way.

How am I’m imposing anything here Alex? It is you that's instating that  just 
in time code that follows the PAYG principal as documented and that has zero 
practical overhead is not PAYG.

From my understanding several people are unclear of what PAYG actually is and 
there are several differing options on what it is. Perhaps the definition that 
you pointed to needs to be updated as you said it is 4 years old.

Wouldn’t it be best to document it so we can all be on the same page?

Thanks,
Justin

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[piotrz]

Yep. It should. I did fix yesterday and monitoring it all the time. :) I
would also be against if Maven build is not working. :)

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/LAST-CALL-Release-FlexJS-FalconJX-0-8-0-tp61275p62154.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[piotrz]

Chris,

But my understanding was that is not working in develop branch and when we
merge release to it - should work. Am I wrong? 

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/LAST-CALL-Release-FlexJS-FalconJX-0-8-0-tp61275p62153.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Christofer Dutz]

Ok … just saw that it seems to be working again … 

Chris

Am 06.06.17, 09:42 schrieb "Christofer Dutz" :

Well I’d say as long as the Maven build doesn’t work, that’s a no-go from 
my side.

Chris

Am 06.06.17, 09:19 schrieb "Alex Harui" :

I think Accordion is now working.  Folks have seen their code work with
Dual.

Is there anything else that is stop-ship?  Otherwise I will start the RC
process tomorrow.

-Alex

On 6/1/17, 2:29 AM, "piotrz"  wrote:

>Thanks Alex! We are blue again [1] :)
>
>[1]

>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.ap

>ache.org%2Fview%2FE-G%2Fview%2FFlex%2Fjob%2FFlexJS%2520Pipeline%2Fjob%2Fre

>lease0.8.0%2F19%2F=02%7C01%7C%7C6ed72c078eb143edec8408d4a8d2c997%7Cfa

>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636319070700456161=H77%2Fy1
>5JaIGG3UuCkbHmz%2FP1iY0gnGjIrqoS05XU%2B6g%3D=0
>
>Piotr 
>
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:

>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle

>x-development.247.n4.nabble.com%2FLAST-CALL-Release-FlexJS-FalconJX-0-

>8-0-tp61275p61990.html=02%7C01%7C%7C6ed72c078eb143edec8408d4a8d2c997%

>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636319070700456161=%2Bf
>2mtw5jkuAqFdrW8K85ipTkL6ogLmWGr%2B5bT0WP%2FC4%3D=0
>Sent from the Apache Flex Development mailing list archive at 
Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Christofer Dutz]

Well I’d say as long as the Maven build doesn’t work, that’s a no-go from my 
side.

Chris

Am 06.06.17, 09:19 schrieb "Alex Harui" :

I think Accordion is now working.  Folks have seen their code work with
Dual.

Is there anything else that is stop-ship?  Otherwise I will start the RC
process tomorrow.

-Alex

On 6/1/17, 2:29 AM, "piotrz"  wrote:

>Thanks Alex! We are blue again [1] :)
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.ap
>ache.org%2Fview%2FE-G%2Fview%2FFlex%2Fjob%2FFlexJS%2520Pipeline%2Fjob%2Fre
>lease0.8.0%2F19%2F=02%7C01%7C%7C6ed72c078eb143edec8408d4a8d2c997%7Cfa
>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636319070700456161=H77%2Fy1
>5JaIGG3UuCkbHmz%2FP1iY0gnGjIrqoS05XU%2B6g%3D=0
>
>Piotr 
>
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FLAST-CALL-Release-FlexJS-FalconJX-0-
>8-0-tp61275p61990.html=02%7C01%7C%7C6ed72c078eb143edec8408d4a8d2c997%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636319070700456161=%2Bf
>2mtw5jkuAqFdrW8K85ipTkL6ogLmWGr%2B5bT0WP%2FC4%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Layout of NumericStepper is broken

[piotrz]

Peter,

I just raised jira -> https://issues.apache.org/jira/browse/FLEX-35322

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Layout-of-NumericStepper-is-broken-tp62108p62149.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[piotrz]

Jira raised for NumericStepper ->
https://issues.apache.org/jira/browse/FLEX-35322



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/LAST-CALL-Release-FlexJS-FalconJX-0-8-0-tp61275p62150.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[piotrz]

Alex,

Yes I think problem with NumericStepper should be fixed [1], cause component
is unusable in that way.

[1]
http://apache-flex-development.247.n4.nabble.com/FlexJS-Layout-of-NumericStepper-is-broken-td62108.html

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/LAST-CALL-Release-FlexJS-FalconJX-0-8-0-tp61275p62147.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Removing PasswordInputBead has no effect

[Alex Harui]

I didn't say it was my project.  Just my vision.  And for the past 4
years, others seem to share it.  I believe that is consensus.  Bertrand
advised us many years ago to make things modular, which FlexJS is, so
folks with different opinions can go implement their opinion in a
different module.  That is the Apache Way.

Imposing your different opinion in others is not the Apache Way.

Thanks,
-Alex

On 6/5/17, 3:16 PM, "Justin Mclean"  wrote:

>Hi,
>
>> If you have a different vision, you can execute that vision in another
>> component set or fork FlexJS entirely.  Please do not impose your vision
>> on my vision.
>
>Since when is this your project Alex or that the project has to only
>include your vision? That is not the Apache way.
>
>I would prefer that we all come to a consensus of what PAYG means and
>clearly document it rather that you dictating it.
>
>Thanks,
>Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[piotrz]

Hi Justin,

Agree with you that we may not everywhere applying in PAYG manner, probably
you will find more examples, but there is no point to do this. I think you
can just try to fix that, cause that's what for we are here I think. :)

I'm done with those discussion in case of changes with that Bead - don't
want to fight about those couple of lines. You fix one general bug I think
here apart of changes in that Bead - That's good! Thank you for that!

We really need to have some system of micro voting maybe when discussion
ends up on different thoughts and then die without any action or decision.
As you probably see in my previous post I was trying to summarize everything
and propose something, but again discussion towards to different direction.
We have on the plate more such discussion and I really do not know how to
end up them in order to have - "Ok we agreed how to do this - let's
implement!" - Maybe discuss my concerns in the other thread please.

Piotr






-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Removing-PasswordInputBead-has-no-effect-tp62092p62146.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Alex Harui]

I think Accordion is now working.  Folks have seen their code work with
Dual.

Is there anything else that is stop-ship?  Otherwise I will start the RC
process tomorrow.

-Alex

On 6/1/17, 2:29 AM, "piotrz"  wrote:

>Thanks Alex! We are blue again [1] :)
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.ap
>ache.org%2Fview%2FE-G%2Fview%2FFlex%2Fjob%2FFlexJS%2520Pipeline%2Fjob%2Fre
>lease0.8.0%2F19%2F=02%7C01%7C%7C6ed72c078eb143edec8408d4a8d2c997%7Cfa
>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636319070700456161=H77%2Fy1
>5JaIGG3UuCkbHmz%2FP1iY0gnGjIrqoS05XU%2B6g%3D=0
>
>Piotr 
>
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FLAST-CALL-Release-FlexJS-FalconJX-0-
>8-0-tp61275p61990.html=02%7C01%7C%7C6ed72c078eb143edec8408d4a8d2c997%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636319070700456161=%2Bf
>2mtw5jkuAqFdrW8K85ipTkL6ogLmWGr%2B5bT0WP%2FC4%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Accordion broken

[Alex Harui]

I just pushed changes that make Accordion look ok to me on both SWF and
JS.  

This is the test case I used.

https://paste.apache.org/ELvN

-Alex


On 6/5/17, 10:57 PM, "yishayw"  wrote:

>Not sure I understand. Is release Accordion working with the example I
>posted
>[1]?
>
>I just fetched and logged flex-asjs and couldn't see any accordion related
>changes. Can you send a commit id?
>
>Thanks.
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FQUj1=02%7C01%7C%7Cdfe8b2d30dc44076114908d4aca2fece%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636323263446558116=g0Pmu%2B4Hxz
>6UTkQDr9UFrY99G5iWFW%2BoM6GaQYQpDsU%3D=0
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p6213
>2.html=02%7C01%7C%7Cdfe8b2d30dc44076114908d4aca2fece%7Cfa7b1b5a7b3443
>8794aed2c178decee1%7C0%7C0%7C636323263446558116=nIdep75b00l93OzUSqjK
>w86fgi48S6H4ktZhLFFHXKs%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: [FlexJS] DataBinding Problem

[piotrz]

It will work for you, but your raised bug is more general thing. Almost each
component has model - what if I would like to change that model on the fly ?

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-tp62073p62143.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: [FlexJS] DataBinding Problem

[Yishay Weiss]

It looks like Alex is modifying Panel to fix the problem in Accordion. I’m good 
with that.

From: piotrz
Sent: Tuesday, June 6, 2017 10:10 AM
To: dev@flex.apache.org
Subject: Re: [FlexJS] DataBinding Problem

I think we can make it as feature request and Yishay probably need to handle
"modelChanged" event on your own to have such code working on the fly.

What do you think Yishay ?

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-tp62073p62141.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] DataBinding Problem

[piotrz]

I think we can make it as feature request and Yishay probably need to handle
"modelChanged" event on your own to have such code working on the fly.

What do you think Yishay ?

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-tp62073p62141.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

>  Unless something is functionality that you would (virtually) always need, 
> it’s a separate bead.

So for CCS we have border, does everyone need borders? Why do we only a sub set 
of the font attributes included? Some people are not going to use all of them 
or in fact any of them and some other may need other properties so why are they 
not seperate?  Not that I think these should be removed into seperate parts. 
The issue is just about every feature you can name is going to optional to 
someone. So I think we near a clearer definition of what PAYG is.

Another example why for instance was flexGrow and flexShrink added in to the 
CSS code? Shouldn't they be implemented in line with the PAYG principal in 
another class? And there are numerous other examples of this. I feel that PAYG 
is not being applied consistently and seems selective on who is making the 
contribution.

> PAYG is already well understood

IMO it has not been clearly defined. Alex has described in various ways as it 
size / runtime cost only to move to goal posts. I for one would like a clearer 
definition of it.

> All functionality should be implemented as beads when practical. Beads should 
> be as modular as possible with the smallest possible functional set.

What about the cost of violating DRY or the single responsibility principal 
which two beads do similar things? Is it really OK to add technical debt / 
penalise users of a new feature when it would be less cost modifying/improving 
an existing bead at a much smaller cost? How do you discourage copy paste 
coding?

Thanks,
Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Justin Mclean]

Hi,

> The wiki from 4 years ago is very helpful in understanding architectural 
> decisions:
> https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype 
>  
>  >


The code I checked is as far a I can tell in line with the principal as 
described there:
"Everything should be "pay as you go" or "just in time" or "on demand". The 
current Flex framework is slow because it runs a lot of code "just-in-case". 
For example most mobile apps initialize a PopupManager. And other code sets up 
a layer for custom cursors. No need to do that unless you are really going to 
use it.”

There's no extra initialisation and the cost of removing the password feature 
is on demand.

Thanks,
Justin

Re: [FlexJS] Removing PasswordInputBead has no effect

[Alex Harui]

This was first published in 2012.

https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype

PAYG and avoiding just-in-case code is mentioned in that document.  As are
Beads.

Thanks,
-Alex

On 6/5/17, 11:33 PM, "Greg Dove"  wrote:

>Harbs, a quick comment from the sidelines on: "PAYG is already well
>understood"
>
>I don't really think that is the case, at least it has not been for me. I
>had a more general notion of PAYG that was nothing to do with beads at
>all,
>and was limited to guesswork/my own interpretation of it at the beginning
>because there was no clear definition.
>
>Unless this is documented somewhere then I believe it is actually a
>barrier
>(of understanding) for people getting involved. If there's already a
>difficulty with 'thinking this way' and 'acting this way' as you indicated
>when you had started and had understood it, then it seems important that
>it
>should also be easily understood in the first place in order to make
>things
>easier for people wanting to participate.
>
>As with a lot of things, once you 'know' it you can tend to take if for
>granted that everyone else does too. But I think you already hinted at
>that
>with what you said...
>
>I am of the opinion that 'vision', 'mission', 'goals' and even
>'architecture' etc don't really exist in a form that is useful for shared
>understanding unless they are documented in some way. And no, 'it's
>obvious
>from the source code' is not what I mean :).
>They are not considered to do so in many other scenarios, in any case, and
>I can't understand why it would be different in an open source project,
>although I definitely have not spent time comparing projects to find out
>what others do here.
>
>
>On Tue, Jun 6, 2017 at 5:21 PM, Harbs  wrote:
>
>> We’ve all already been implementing things as Alex states. He
>>architected
>> the framework and it’s a good architecture. No need to change things. We
>> need consistent architecture. We can’t have a free-for-all...
>>
>> Percentage of code really has nothing to do with it. Unless something is
>> functionality that you would (virtually) always need, it’s a separate
>>bead.
>> That’s the way the whole SDK is implemented. If there are cases where
>>it’s
>> not, it’s a bug and should be fixed. Removal of password functionality
>>is
>> NOT usually required for password beads.
>>
>> PAYG is already well understood: All functionality should be implemented
>> as beads when practical. Beads should be as modular as possible with the
>> smallest possible functional set.
>>
>> That’s pretty much it. It’s difficult to make the mental switch to
>>working
>> this way. I had similar difficulty when I started implementing things
>>for
>> FlexJS. It takes some getting used to, but it’s a very good design.
>>
>> Harbs
>>
>> > On Jun 6, 2017, at 1:16 AM, Justin Mclean 
>> wrote:
>> >
>> > Hi,
>> >
>> >> If you have a different vision, you can execute that vision in
>>another
>> >> component set or fork FlexJS entirely.  Please do not impose your
>>vision
>> >> on my vision.
>> >
>> > Since when is this your project Alex or that the project has to only
>> include your vision? That is not the Apache way.
>> >
>> > I would prefer that we all come to a consensus of what PAYG means and
>> clearly document it rather that you dictating it.
>> >
>> > Thanks,
>> > Justin
>>
>>

Re: [FlexJS] Removing PasswordInputBead has no effect

[Harbs]

The wiki from 4 years ago is very helpful in understanding architectural 
decisions:
https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype 


If you have suggestions to make things clearer then by all means suggest 
something.

Thanks,
Harbs

> On Jun 6, 2017, at 9:33 AM, Greg Dove  wrote:
> 
> Harbs, a quick comment from the sidelines on: "PAYG is already well
> understood"
> 
> I don't really think that is the case, at least it has not been for me. I
> had a more general notion of PAYG that was nothing to do with beads at all,
> and was limited to guesswork/my own interpretation of it at the beginning
> because there was no clear definition.
> 
> Unless this is documented somewhere then I believe it is actually a barrier
> (of understanding) for people getting involved. If there's already a
> difficulty with 'thinking this way' and 'acting this way' as you indicated
> when you had started and had understood it, then it seems important that it
> should also be easily understood in the first place in order to make things
> easier for people wanting to participate.
> 
> As with a lot of things, once you 'know' it you can tend to take if for
> granted that everyone else does too. But I think you already hinted at that
> with what you said...
> 
> I am of the opinion that 'vision', 'mission', 'goals' and even
> 'architecture' etc don't really exist in a form that is useful for shared
> understanding unless they are documented in some way. And no, 'it's obvious
> from the source code' is not what I mean :).
> They are not considered to do so in many other scenarios, in any case, and
> I can't understand why it would be different in an open source project,
> although I definitely have not spent time comparing projects to find out
> what others do here.
> 
> 
> On Tue, Jun 6, 2017 at 5:21 PM, Harbs  wrote:
> 
>> We’ve all already been implementing things as Alex states. He architected
>> the framework and it’s a good architecture. No need to change things. We
>> need consistent architecture. We can’t have a free-for-all...
>> 
>> Percentage of code really has nothing to do with it. Unless something is
>> functionality that you would (virtually) always need, it’s a separate bead.
>> That’s the way the whole SDK is implemented. If there are cases where it’s
>> not, it’s a bug and should be fixed. Removal of password functionality is
>> NOT usually required for password beads.
>> 
>> PAYG is already well understood: All functionality should be implemented
>> as beads when practical. Beads should be as modular as possible with the
>> smallest possible functional set.
>> 
>> That’s pretty much it. It’s difficult to make the mental switch to working
>> this way. I had similar difficulty when I started implementing things for
>> FlexJS. It takes some getting used to, but it’s a very good design.
>> 
>> Harbs
>> 
>>> On Jun 6, 2017, at 1:16 AM, Justin Mclean 
>> wrote:
>>> 
>>> Hi,
>>> 
 If you have a different vision, you can execute that vision in another
 component set or fork FlexJS entirely.  Please do not impose your vision
 on my vision.
>>> 
>>> Since when is this your project Alex or that the project has to only
>> include your vision? That is not the Apache way.
>>> 
>>> I would prefer that we all come to a consensus of what PAYG means and
>> clearly document it rather that you dictating it.
>>> 
>>> Thanks,
>>> Justin
>> 
>> 

Re: [FlexJS] DataBinding Problem

[Alex Harui]

I have local changes that fixes Binding in Accordion by changing the
lifecycle of the underlying Panel that AccordionItemRenderer subclasses.
I'll push them before I shut down for the day.  I want to try to fix the
TitleBar height issue on JS first.

The reasoning is that ItemRenderers are supposed to have a different
lifecycle.  Normally, Binding is run as soon as the component is added as
a child.  But in renderers, Binding and layout isn't worth running at that
point in the lifecycle because just about everything is dependent on the
"data" property.  So, the changes you'll see is that the
AccordionItemRendererView overrides PanelView's completeSetup() and
doesn't add the TitleBar or layout the renderer until data is set, which
is after the model gets shared.

FLEX-35320 is theoretically a feature request.  The current Binding
implementation doesn't support changing the "host", but a fancier, fatter
and slower Binding implementation can.  PAYG and all that.

Thanks,
-Alex

On 6/5/17, 11:12 PM, "yishayw"  wrote:

>It's actually MXMLBeadViewDataBinding. The simplest solution may be to
>avoid
>using binding in TitleBarView and explicitly listen to TitleBar's
>"modelChanged" event and TitleBarModel's "titleChange" event. But any
>other
>solution is fine by me.
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-DataBinding-Problem-tp62073p6
>2133.html=02%7C01%7C%7Cb938b4dde0754478487808d4aca52e82%7Cfa7b1b5a7b3
>4438794aed2c178decee1%7C0%7C0%7C636323272830510197=iBHXLtdzCt6HDZbJZ
>1eEaUL139K5F%2Bm7fEo9hAG5FbU%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] DataBinding Problem

[piotrz]

Alex,

I was thinking about that more and more. I think the way how
MXMLBeadViewDataBinding decided what binding has been chosen in case of
TitleBarView is ok. - We probably shouldn't change anything in that matter.

Exchange model - That's more global thing - cause if we allow for this in
case of TitleBar/Panel the other components need to be also able to do this. 

Yishay,

It's class related to binding for example MXMLBeadViewDataBinding - has
complex condition which decide what kind of binding actually should be used:
Generic, SimpleDataBinding or ConstanBinding. 

Piotr 



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-tp62073p62135.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Removing PasswordInputBead has no effect

[Greg Dove]

Harbs, a quick comment from the sidelines on: "PAYG is already well
understood"

I don't really think that is the case, at least it has not been for me. I
had a more general notion of PAYG that was nothing to do with beads at all,
and was limited to guesswork/my own interpretation of it at the beginning
because there was no clear definition.

Unless this is documented somewhere then I believe it is actually a barrier
(of understanding) for people getting involved. If there's already a
difficulty with 'thinking this way' and 'acting this way' as you indicated
when you had started and had understood it, then it seems important that it
should also be easily understood in the first place in order to make things
easier for people wanting to participate.

As with a lot of things, once you 'know' it you can tend to take if for
granted that everyone else does too. But I think you already hinted at that
with what you said...

I am of the opinion that 'vision', 'mission', 'goals' and even
'architecture' etc don't really exist in a form that is useful for shared
understanding unless they are documented in some way. And no, 'it's obvious
from the source code' is not what I mean :).
They are not considered to do so in many other scenarios, in any case, and
I can't understand why it would be different in an open source project,
although I definitely have not spent time comparing projects to find out
what others do here.


On Tue, Jun 6, 2017 at 5:21 PM, Harbs  wrote:

> We’ve all already been implementing things as Alex states. He architected
> the framework and it’s a good architecture. No need to change things. We
> need consistent architecture. We can’t have a free-for-all...
>
> Percentage of code really has nothing to do with it. Unless something is
> functionality that you would (virtually) always need, it’s a separate bead.
> That’s the way the whole SDK is implemented. If there are cases where it’s
> not, it’s a bug and should be fixed. Removal of password functionality is
> NOT usually required for password beads.
>
> PAYG is already well understood: All functionality should be implemented
> as beads when practical. Beads should be as modular as possible with the
> smallest possible functional set.
>
> That’s pretty much it. It’s difficult to make the mental switch to working
> this way. I had similar difficulty when I started implementing things for
> FlexJS. It takes some getting used to, but it’s a very good design.
>
> Harbs
>
> > On Jun 6, 2017, at 1:16 AM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> >> If you have a different vision, you can execute that vision in another
> >> component set or fork FlexJS entirely.  Please do not impose your vision
> >> on my vision.
> >
> > Since when is this your project Alex or that the project has to only
> include your vision? That is not the Apache way.
> >
> > I would prefer that we all come to a consensus of what PAYG means and
> clearly document it rather that you dictating it.
> >
> > Thanks,
> > Justin
>
>

Re: [FlexJS] DataBinding Problem

[yishayw]

It's actually MXMLBeadViewDataBinding. The simplest solution may be to avoid
using binding in TitleBarView and explicitly listen to TitleBar's
"modelChanged" event and TitleBarModel's "titleChange" event. But any other
solution is fine by me.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-DataBinding-Problem-tp62073p62133.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Accordion broken

[yishayw]

Not sure I understand. Is release Accordion working with the example I posted
[1]?

I just fetched and logged flex-asjs and couldn't see any accordion related
changes. Can you send a commit id? 

Thanks.

[1] https://paste.apache.org/QUj1



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Accordion-broken-tp61937p62132.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.