Changes for page Best Practices-Model

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,7 +1,5 @@
1	1	{{warning title="In construction"}}
2		-
3		-This chapter is under construction. Do not expect it to be useful... yet! :)
4		-
	2	+This chapter is under construction. Do not expect it to be useful... yet!
5	5	{{/warning}}
6	6
7	7	= Model =
...	...	@@ -18,11 +18,11 @@
18	18
19	19	* There are some things EOF simply can't guess. If you have a String, you need to decide how much space you want to use on the database for it. If you know the String will contain a color, like "Red" or "Yellow", something like a varchar 50 should be enough. On the other end, if the String will be used to store a full name of a user, you probably want to make it a varchar 1000 or so (European names can be very long!). Of course, most databases allow you to use unlimited text data types, but that has serious implications in the database speed. So, it's up to you.
20	20
21		-* YMMV however, Postgresql recommends that you use a column of type text. Their documentation states there is no speed penalty for choosing this over varchar(some number). The Entity Modeler prototype is 'longText'
	19	+* YMMV however, Postgresql recommends that you use a column of type text. Their documentation states there is no speed penalty for choosing this over varchar(some number). The Entity Modeler prototype is 'longText'
22	22
23	23	* You may be constrained to existing data types. If you are building an WO application on top of an existing database with millions of records, you cannot choose the data types you want to use - you must use the existing ones used by the database. So, you have to tell EOF what types are those, so that it can read and write information to your existing database.
24	24
25		-If you already tried to create a model, by following [[Janine's tutorial>>http://wotutorial.furfly.com/downloads.html]] or so, you know how flexible it can be - and how tedious it is. It shouldn't be needed to choose, for every integer in your model, the data type for it. Or the data type for every primary key. Or the data type for every string. Worse, if you decide you want to use higher precision floats on all your application, or if you want to increase the size of some of the strings you use in your data model, you should be able to change that information on only one place. After all, duplicating code is bad, right? So why can't you do it?
	23	+If you already tried to create a model, by following [[Janine's tutorial>>url:http://wotutorial.furfly.com/downloads.html||shape="rect"]] or so, you know how flexible it can be - and how tedious it is. It shouldn't be needed to choose, for every integer in your model, the data type for it. Or the data type for every primary key. Or the data type for every string. Worse, if you decide you want to use higher precision floats on all your application, or if you want to increase the size of some of the strings you use in your data model, you should be able to change that information on only one place. After all, duplicating code is bad, right? So why can't you do it?
26	26
27	27	Well, you can! That's what prototypes are for. A prototype allows you to:
28	28
...	...	@@ -34,7 +34,7 @@
34	34
35	35	Let's look at an example for a prototype. This is the definition of "shortString", a prototype defined in the WONDER's ERPrototypes framework (we'll talk more about this framework later). The screenshot was taken from the Entity Modeler plugin in Eclipse, part of WOLips.
36	36
37		-[[image:prototypeExample.png]]
	35	+[[image:attach:prototypeExample.png]]
38	38
39	39	We can see here that:
40	40
...	...	@@ -47,19 +47,19 @@
47	47
48	48	You can create your own prototype definitions, or use WONDER's.
49	49
50		-To create your own prototypes, you need to create a special entity in a model file called ##EOJDBCPrototypes##. It's recommended that you create a new model file with just the prototype entity, and place that file in a new, empty framework. This way you can share the same prototypes with all of your projects, and you may switch between prototype frameworks to use different databases without making any modification on your application.
	48	+To create your own prototypes, you need to create a special entity in a model file called {{code language="none"}}EOJDBCPrototypes{{/code}}. It's recommended that you create a new model file with just the prototype entity, and place that file in a new, empty framework. This way you can share the same prototypes with all of your projects, and you may switch between prototype frameworks to use different databases without making any modification on your application.
51	51
52		-WONDER prototype framework, ERPrototypes, has different prototype entities, one for each database. The one for Postgresql framework is called ##EOJDBCPostgresqlPrototypes## and so on. To use those prototypes, just link your project with ERPrototypes after installing WONDER. Then, on your model database configuration, choose the right prototype in the appropriate menu:
	50	+WONDER prototype framework, ERPrototypes, has different prototype entities, one for each database. The one for Postgresql framework is called {{code language="none"}}EOJDBCPostgresqlPrototypes{{/code}} and so on. To use those prototypes, just link your project with ERPrototypes after installing WONDER. Then, on your model database configuration, choose the right prototype in the appropriate menu:
53	53
54		-[[image:prototypeSelection.png]]
	52	+[[image:attach:prototypeSelection.png]]
55	55
56		-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	+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 {{code language="none"}}shortString{{/code}} 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.
57	57
58	58	Before:
59		-[[image:prototypesBefore.png]]
	57	+[[image:attach:prototypesBefore.png]]
60	60
61	61	After:
62		-[[image:prototypesAfter.png]]
	60	+[[image:attach:prototypesAfter.png]]
63	63
64	64	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.
65	65