= 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.