Changes between Version 39 and Version 40 of PRO_LIB_CORE_TUTORIAL

Timestamp:

07/14/09 14:38:47 (16 years ago)

Author:

peko

Comment:

--

PRO_LIB_CORE_TUTORIAL

@@ -699 +699 @@
 }}}
   
-  * People tend to the the following in order to initialize the prorperty:
-{{{
-button().get();
-}}}
-  * '''This actually will do nothing. The property is automatically created and initialized when the value property containing the tool-tip is initialized!'''
+   * People tend to the the following in order to initialize the prorperty:
+{{{
+button().get(); //does nothing!
+}}}
+   * '''This actually will do nothing. The property is automatically created and initialized when the value property containing the tool-tip is initialized!''' Same applied to auto properties! You do not need to "get()" the property in order for it to be "computed". This is automatically provided by the pro lib.
+  * Using a non-ProObject or non-@Immutable object as a value of a property:
+{{{
+        class BadObject { //does not extend ProObject and is not annotated with @Immutable
+                
+        }
+        
+        public RwProp<BadObject> badObject() {
+                return getBean().makeValueProp("badObject", BadObject.class);
+        }
+}}}
+   * '''This should never happen.''' Every object that is a value of a property or is a value in a list property should either be a ProObject or an Immutable. Having objects like this one will never force an AutoProperty update if this AutoProperty depends on the "badObject()'s" property. Same applied to other properties depending on "badObject()'s" property. If a non-ProObject or non-@Immutable is really needed, use the resource property, where it is created and different things are set to it.
 
 == Debugging ProLib ==