| | 218 | * Although I think the above example is much more sophisticated, I also add this one by His Holy Meddleness request along with his comments: |
| | 219 | {{{ |
| | 220 | The @Const AutoProperties rarely depend on anything, they are "bottom" properties that can calculate themselves by themselves only once. |
| | 221 | The greatest example for such an AutoProperty is: |
| | 222 | |
| | 223 | @Const |
| | 224 | public Prop<Link> link() { |
| | 225 | class link extends AutoProperty<Link> { |
| | 226 | |
| | 227 | @Override |
| | 228 | protected Link compute() { |
| | 229 | assert getLastValue() == null; |
| | 230 | return new FrameLink(getChangeManager()); |
| | 231 | } |
| | 232 | } |
| | 233 | return getBean().makeProp(link.class); |
| | 234 | } |
| | 235 | }}} |
| | 236 | |
| 268 | | * Further more, the setup() method can be "split" in pieces by the '''@Setup''' annotation. In the ResourceProperty descendant class you provide, swingComponent in our case, you can provide a multitude of methods which are annotated with @Setup and together they form the logic for updating the ResourceProperty. This is useful form performance reasons, because let's say you've got a very heavy setup() method which consists of logically independent parts P1 and P2, and P1 depends on some Property X while P2 doesn't depend on X so when X changes, P2 doesn't need to be executed again. Thus, providing two new setup methods which correspond to P1 and P2 leads to performance optimization (and capsulation of independent code in different methods) because the ProLib is smart enough to invoke only the needed setup methods. |
| | 287 | * Further more, the setup() method can be "split" in pieces by the '''@Setup''' annotation. In the ResourceProperty descendant class you provide, swingComponent in our case, you can provide a multitude of methods which are annotated with @Setup and together they form the logic for updating the ResourceProperty. This is useful form performance reasons, because let's say you've got a very heavy setup() method which consists of logically independent parts P1 and P2, and P1 depends on some Property X while P2 doesn't depend on X so when X changes, P2 doesn't need to be executed again. Thus, providing two new setup methods which correspond to P1 and P2 leads to performance optimization (and capsulation of independent code in different methods) because the ProLib is smart enough to invoke only the needed setup methods. You should note though that the order of invoking the @Setup methods is undefined and you shouldn't depend on this because it can change. |
