Properties Idea

Properties give solution to the sequence of problems:

• Initialization order problems
• Dependency/updating
• Undo/Redo
• Save/Load
• Optimization (central point)
• Safety (detect errors)

Properties Kinds

• Property
  • ObjectProperty - A property which holds a reference to a single object.
    • FinalProperty - One time write property. Once set, its value never changes.
    • AutoProperty - Smart property. A property which automatically monitors the information it depends on. In order to work, it should rely only on other properties and immutable values.
    • ResourceProperty - A property which holds a mutable resource. Useful for mutable non pro things like swing gui elements.
    • ValueProperty - A property that has a reference to an object and allows getting and setting it.
      • ParentProperty - Property which will hold a link to parent for parent-child relations.
      • UndoProperty - A property which holds the undo manager for given bean. If the bean does not have such property, the properties try to locate UndoManager up (to parent).
  • ListProperty - Basic list property. Holds references to many objects.
    • ChildrenProperty - Property which manages list of children for a child/parent relation.

Code Examples with different Properties Kinds

How to make

• FinalProperty

          public Prop<FrameView> frameView() {
  		return getBean().makeFinalProp("frameView", FrameView.class);
  	}
  

• AutoProperty

  	public Prop<JScrollPane> scrollPane() {
  		class scrollPane extends AutoProperty<JScrollPane> {
  			@Override
  			protected JScrollPane compute() {
  				JScrollPane res = new JScrollPane(list().get());
  
  				res.setVerticalScrollBarPolicy(
  						ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS);
  
  				return res;
  			}
  		}
  		return getBean().makeReadProp(scrollPane.class);
  	}
  

• ResourceProperty

  	public Prop<JMenu> swingMenu() {
  		class swingMenu extends ResourceProperty<JMenu> {
  
  			@Override
  			protected JMenu create() {
  				return new JMenu();
  			}
  
  			@Override
  			protected void destroy(JMenu resource) {
  				// TODO Auto-generated method stub
  				
  			}
  
  			@Override
  			protected void setup(JMenu res) {
  				List<MenuMember> data = items().get();
  				assert data.size() == 0 || Collections.frequency(data, data.get(0)) == 1 : data;
  				
  				res.removeAll();
  				for(MenuMember m : data) {
  					res.add(m.swingMenu().get());
  				}
  			}
  		}
  		return getBean().makeReadProp(swingMenu.class);
  	}
  

• ParentProperty

          public RwProp<Page> parent() {
  		return getBean().makeParentProp(Page.class, "frames");
  	}
  

• UndoProperty

          public UndoProperty undoManager() {
  		return getBean().makeUndoProperty();
  	}
  

• ChildrenProperty

  	public RwListProp<PageView> pageViews() {
  		class PageViews extends ChildrenProperty<PageView> {
  			@Override
  			protected ListBinding<?, PageView> getListBinding() {
  				return new BaseListBinding<Page, PageView>() {
  
  					@Override
  					protected PageView translateSourceToTarget(Page source) {
  						return new PageView(source);
  					}
  
  					@Override
  					protected RwListProp<Page> computeSource() {
  						return model().get().pages();
  					}
  				};
  			}
  		}
  
  		return getBean().makeListProp(PageViews.class);
  	}
  

Bad Code Examples

• Resource Property is a better choice.

        public Prop<JComponent> swingComponent() {
		class swingComponent extends AutoProperty<JComponent> {
			@Override
			protected JComponent compute() {
				JComponent res = new JPanel();
				res.setLayout(new BoxLayout(res, BoxLayout.Y_AXIS));
				res.setPreferredSize(new Dimension(100, 100));
				res.add(headComponent().get());
				res.add(scrollPane().get());
				res.setVisible(true);
				res.validate();
        
				return res;
			}
		}
		return getBean().makeReadProp(swingComponent.class);
	}

How to apply properties to Sophie 2.0

• To get rid of the fields, except for immutable classes, and public static final things.
  • Note that final instance fields are not so safe, because they are initialized after the super constructors.
• To convert mutable classes to ProObjects
• To gather more requirements to the properties library and apply them
• To keep the properties library with high quality, because everything else will depend on it.
• To be careful of cyclic dependencies (like a = b + 1, b = a + 1). No library can solve them.