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
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:
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
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
is message in context:
http://apache-flex-development.247.n4.nabble.com/Beads-and-DRY-was-Re-FlexJS-Removing-PasswordInputBead-has-no-effect-tp62177p62209.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Hi,
> Personally I prefer this approach even if it is more code.
I assume you mean subclassing over utility functions?
Thanks,
Justin
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
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
le.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.
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
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
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.
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
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
14 matches
Mail list logo