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

I actually added VerticalLayoutWithPaddingAndGap recently. I didn't want to set margins because a gap property is much more convenient in many situations. :) - Josh On Wed, Jun 7, 2017 at 7:15 AM, Peter Ent wrote: > If you look at the layouts, you can see these

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

We have never really discussed the use of delegates. Its not something that ties in that well with FlexJS I think. But using a delegate to off-load some of the work, just when that work is needed, might be another solution. ‹peter On 6/7/17, 2:36 AM, "Harbs" wrote:

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

If you look at the layouts, you can see these questions for real. Take VerticalLayout. The idea is to stack children of some component vertically. Those children can be given a) no explicit size, b) an explicit size as pixel values, c) a percentage size. You know what the VerticalLayout is

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

That’s not what I’m suggesting at all. If utility classes (or utility functions) are bloated with lots of functionality then they are not done right. Utilities should be reserved for well defined functionality. A good example of this is AnimationUtil. Imagine you have two animation beads which

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

Hi Justin, I mean take some part of code from class A to B (could be inheritance) in order to have new functionality. Bead B is doing only Y. "Bead B extends Bead A and adds code for feature Y (no extra code)" Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in

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

Hi, > Personally I prefer this approach even if it is more code. I assume you mean subclassing over utility functions? Thanks, Justin

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

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

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

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

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

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:

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

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

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

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

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

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: Beads and DRY (was Re: [FlexJS] Removing PasswordInputBead has no effect)

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

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

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

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

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