You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+24-14Lines changed: 24 additions & 14 deletions
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,9 @@ JDS is licensed under the [3-Clause BSD License](https://opensource.org/licenses
28
28
29
29
The concept behind JDS is quite simple. Extend a base **Entity** class, define strongly-typed **Fields** and then **map** them against implementations of the **Property** interface.
30
30
31
-
JDS was designed to avoid reflection, and its potential performance implications, as such mapping is used as oppossed to using Annotations .
31
+
JDS was designed to avoid reflection and its potential performance pitfalls.
32
+
As such mapping functions which are overridden, and invoked at least once at runtime, are used to enforce/validate typing as instead of annotations.
33
+
This is discussed below in section 1.1.4 "Binding properties".
@@ -100,22 +102,25 @@ public interface IAddress : IEntity
100
102
publicclassAddress : IAddress
101
103
```
102
104
103
-
Following that the following steps need to be taken.
104
-
105
105
### 1.1.1 Annotating Classes
106
106
107
-
Every class that extends Entity must have its own unique Entity Id as well as an Entity Name. This is done by annotating the class, or its parent interface, in the following manner
107
+
Every class/interface which extends Entity/IEntity must have its own unique Entity ID as well as an Entity Name.
108
+
This is done by annotating the class, or its (parent) interface.
108
109
109
110
```kotlin
110
111
@EntityAnnotation(id =1, name ="address", description ="An entity representing address information")
111
112
classAddress : Entity()
112
113
```
113
114
114
-
Entity IDs MUST be unique in your application, any value of type long is valid. Entity Names do not enforce unique constraints but its best to use a unique name regardless. These values can be referenced to mine data.
115
+
Entity IDs MUST be unique in your application, any value of type long is valid.
116
+
Entity Names do not enforce unique constraints but its best to use a unique name regardless.
117
+
These values can be referenced to mine data.
115
118
116
119
### 1.1.2 Defining Fields
117
120
118
-
Fields are big part of the JDS framework. Each Field MUST have a unique Field Id. Field Names do not enforce unique constraints but its best to use a unique name regardless. These values can be referenced to mine data. Every Field that you define can be one of the following types.
121
+
Fields are big part of the JDS framework.
122
+
Each Field MUST have a unique Field Id. Field Names do not enforce unique constraints but its best to use a unique name
123
+
regardless. These values can be referenced to mine data. Every Field that you define can be one of the following types.
Furthermore you can add descriptions, of up to **256 characters**, to each field
175
+
Furthermore, you can add descriptions, of up to **256 characters**, to each field
171
176
172
177
```kotlin
173
178
importio.github.subiyacryolite.jds.Field;
@@ -181,7 +186,9 @@ object Fields {
181
186
}
182
187
```
183
188
184
-
JDS also supports **Tags** which can be applied to each **Field** and **Entity** definitions. Tags are implemented as a set of strings, there is no limit on how many tags a field can have. This can be useful for categorising certain kinds of information
189
+
JDS also supports **Tags** which can be applied to each **Field** and **Entity** definitions. Tags can be defined as a
190
+
set of strings, there is no limit on how many tags a field can have. This can be useful for categorising certain kinds
191
+
of information
185
192
186
193
```kotlin
187
194
importio.github.subiyacryolite.jds.Field;
@@ -195,9 +202,9 @@ object Fields {
195
202
196
203
### 1.1.3 Defining Enums
197
204
198
-
Enums are an extension of **Fields**. However, they are designed for cases where one or more constant values are required. Usually these values would be represented by Check Boxes, Radio Buttons or Combo Boxes in a UI. In this example we will define the type of an address as an enumerated value with the following options (YES, NO).
205
+
JDS Enums are an extension of **Fields**. Usually these values would be represented by Check Boxes, Radio Buttons or Combo Boxes on the front-end.
199
206
200
-
First of all we'd have to define a standard Field of type **Enum**.
207
+
First we'd define a standard JDS Field of type **Enum**.
201
208
202
209
```kotlin
203
210
importio.github.subiyacryolite.jds.Field
@@ -217,6 +224,8 @@ enum class Direction {
217
224
}
218
225
```
219
226
227
+
Lastly, we create an instance of the JDS Field Enum type.
228
+
220
229
```kotlin
221
230
importio.github.subiyacryolite.jds.FieldEnum
222
231
@@ -311,15 +320,16 @@ To simplify the mapping Process Jds has the following helper classes defined:
311
320
312
321
**Note:** Collection types can be of any valid type e.g. ArrayList, LinkedList, HashSet etc
313
322
314
-
After your class and its properties have been defined you must map the property to its corresponding Field using the **map()** method. I recommend doing this in your primary constructor.
323
+
After your class and its properties have been defined you must map the property to its corresponding Field using the **map()** method.
324
+
I recommend doing this in your primary constructor.
315
325
316
326
The example below shows a class definition with valid properties and bindings. With this your class can be persisted.
317
327
318
328
Note that the example below has a 3rd parameter to the map method, this is the **Property Name**
319
329
320
330
The **Property Name** is used by the JDS **Field Dictionary** to know which **property** a particular **Field** is mapped to within an **Entity**.
321
331
322
-
This is necessary as one **Field** definition may be mapped to a different property amongst different **Entities**.
332
+
This is necessary as one **Field** definition can be mapped to a different property amongst different **Entities**.
323
333
324
334
For example a **Field** called "FirstName" could be mapped to a property called "firstName" in one **Entity** and a property called "givenName" in another.
0 commit comments