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 <p...@adobe.com.invalid> 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 supposed to do, but how it does it depends on the > platform. Plus there are some questions: > > Do you provide an option to space them (a gap) or is that > VerticalLayoutWithGap? > Do you provide an option to horizontally align them or is that > VerticalLayoutWithHorizontalAlignment? > What if you want both a gap and an alignment? Is that > VerticalLayoutWithGapAndHorizontalAlignment? > > Achieving a gap and alignment is pretty easy and I believe can be done > within the same loop pass as stacking the elements. > > We circumvented the gap issue by saying you achieving by giving the > children being stacked margin style values. So that eliminates two of the > variations. But that comes at a cost on the SWF side (JS side handles > margins in the browser) since it is way more complex to account for those > margins and it might rightly be put into its own layout bead. > > And when you make these altered versions, its hard to subclass since you > have the layout algorithm that you've have to tap into from the subclass > and then call out or use a delegate. > > ‹peter > > On 6/6/17, 9:08 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" > <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: > > >On Tue, Jun 6, 2017 at 5:29 PM, Justin Mclean <jus...@classsoftware.com> > >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. > >
