Changes for page Best Practices-Model

Last modified by Theodore Petrosky on 2014/02/20 18:51

From version 36.1
edited by arroz
on 2008/02/03 17:54
Change comment: There is no comment for this version
To version 39.1
edited by tcripps
on 2008/04/08 14:18
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.arroz
1 +XWiki.tcripps
Content
... ... @@ -36,7 +36,7 @@
36 36  We can see here that:
37 37  
38 38  * The prototype name is "shortString".
39 -* The external type (ie, the database type) is varchar.
39 +* The external type (i.e., the database type) is varchar.
40 40  * The varchar width is 50, which means you can save up to 50 characters on each record.
41 41  * The Java class that will map the database value in memory is String.
42 42  
... ... @@ -50,7 +50,7 @@
50 50  
51 51  [[image:prototypeSelection.png]]
52 52  
53 -As state before, one of the advantages of using prototypes is that, if you change a prototype definition, your model will automatically use the new definition for all the attributes that are linked to that prototype. There's also an interesting feature here that is worst mentioning. After setting a prototype in a given attribute of your model, you can decide to change some details of the prototype. So, imagine you have a ##shortString## prototype like the one showed above, but you decide that on some specific attribute that links to that prototype that you want the size to me 25 and not 50. You could not use the prototype at all for that attribute, and, instead, defining everything manually. But there's a better way: just set the prototype for smallString, and then, change the size from 50 to 25. When you try that, you'll see the 25 value will show up in black, not brown.
53 +As state before, one of the advantages of using prototypes is that, if you change a prototype definition, your model will automatically use the new definition for all the attributes that are linked to that prototype. There's also an interesting feature here that is worth mentioning. After setting a prototype in a given attribute of your model, you can decide to change some details of the prototype. So, imagine you have a ##shortString## prototype like the one showed above, but you decide that on some specific attribute that links to that prototype that you want the size to me 25 and not 50. You could not use the prototype at all for that attribute, and, instead, defining everything manually. But there's a better way: just set the prototype for smallString, and then, change the size from 50 to 25. When you try that, you'll see the 25 value will show up in black, not brown.
54 54  
55 55  Before:
56 56  [[image:prototypesBefore.png]]
... ... @@ -60,6 +60,6 @@
60 60  
61 61  The brown values are the global values defined by the prototype you chose for that attribute. Those values are directly set by the prototype, which means that, if the prototype changes, the values in that attribute will change too. But when you set the value specifically for that attribute, it will change to black, meaning that your change will override any data from the prototype. So, if you change those values in the prototype, that specific attribute will maintain the values you set, ignoring the prototype.
62 62  
63 -eogenerator
63 +== EOGenerator ==
64 64  
65 -to-many relationships
65 +== To-many relationships ==