packages

[Tyler Wright]

The 'reflex' package is the base for everything right now. I think we should have 'reflex' contain only the component framework, including core classes, utilities, Interfaces, behaviors, etc. Final components would have a unique package representing the actual component set, starting with Button on up through to DataGrid. Then our component set would be built off the reflex component framework, isolating concerns by package and providing room for future growth (a unique mobile component set for example)

thoughts?

Tyler

[Tyler Wright]

Considering the name reflex could be associated with the Flex name (not an official position), suggested names for a component set could be mistakenly associated with the Spark name. Suggestions are Flame or Bolt

[Tyler Wright]

I think component packages should changed from what we're used to. It's common practice to organize the world of components into two packages, controls and containers. A component's behavior determines whether or not it's a control, and it seems the skin would influence the component's ability to be a container. Both behaviors and skins are naturally flexible and change depending on context.

Since a component in the reflex framework is truly a model of its domain we should break out components based on that model. Following is a sketch of some proposed package structure:

• simple - very simple or no model
  
• Button
• CheckBox
• Divider
• Link
• Panel
• text - dealing with text
• Label
  
• Input
• TextArea
• progress - dealing with range
  
• Stepper
• ScrollBar
• Slider
• ProgressBar
  
• list - repetitive in one dimension
• ButtonGroup
• RadioGroup
• ListBox
• Accordian
• ButtonBar
• TabBar
• BreadCrumbs
  
• grid - repetitive in two dimensions
  
• DataGrid
• SpreadSheet
• Calendar
• Form
• complex - composition of many models
• ComboBox
• Alert
• FileMenu
  
• TreeExplorer
• Window

Because we intend to have quite a few components, it will be nice to divide them out between more than just two packages.

Tyler