forked from liferay/liferay-portal
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathliferay-service-builder_4_3_0.dtd
385 lines (309 loc) · 12 KB
/
liferay-service-builder_4_3_0.dtd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
<!--
<!DOCTYPE service-builder PUBLIC
"-//Liferay//DTD Service Builder 4.3.0//EN"
"http://www.liferay.com/dtd/liferay-service-builder_4_3_0.dtd">
-->
<!--
The service-builder element is the root of the deployment descriptor for
a Service Builder descriptor that is used to generate services available to
portlets. The Service Builder saves the developer time by generating Spring
utilities, SOAP utilities, and Hibernate persistence classes to ease the
development of services.
To run the service generator, go to /portal/portal-impl (or /ext/ext-impl) and
type "ant build-service". The ant task will check for the existence of a file
called "service.xml" that must exist in your current directory. It will parse
that file to generate the service.
-->
<!ELEMENT service-builder (portlet, entity+, exceptions?)>
<!--
The root-dir value specifies the root directory of the portal source code. If
you are running the service builder in /portal/portal-impl or /ext/ext-impl,
then the value is just ".." because the root is /portal or /ext.
The package-path value specifies the package of the generated code. If the value
is "com.liferay.portlet", then all generated code will fall inside
"com.liferay.portlet" + the shortened portlet name. The portlet name is
specified in the portlet element. For example, if the portlet name is
"Message Boards", the generated code will fall under
"com.liferay.portlet.messageboards".
-->
<!ATTLIST service-builder
root-dir CDATA #REQUIRED
package-path CDATA #REQUIRED
>
<!--
The portlet element specifies the portlet that the generated services are
designed for. Services are not limited to the specified portlet but are only
grouped by portlet for easier maintenance.
-->
<!ELEMENT portlet (#PCDATA)>
<!--
The name can be something like "Message Boards". It is used by the Service
Builder in combination with the package-path attribute.
The short-name can be something like "MB". This is used as a namespace to
distinguish all the generated objects.
-->
<!ATTLIST portlet
name CDATA #REQUIRED
short-name CDATA #REQUIRED
>
<!--
An entity usually represents a business facade and a table in the database. If
an entity does not have any columns, then it only represents a business facade.
The Service Builder will always generate an empty business facade POJO if it
does not exist. Upon subsequent generations, the Service Builder will check to
see if the business facade already exists. If it exists and has additional
methods, then the Service Builder will also update the SOAP wrappers.
If an entity does have columns, then the value object, the POJO class that
is mapped to the database, and other persistence utilities are also generated
based on the order and finder elements.
-->
<!ELEMENT entity (column*, order?, finder*)>
<!--
The name value specifies the name of the entity.
The table value specifies the name of the table that this entity maps to in the
database. If this value is not set, then the name of the table is the same as
the name of the entity name.
If the local-service is true, then the service will generate the local
interfaces for the service. The default value is false.
If the remote-service is true, then the service will generate remote interfaces
for the service. The default value is true.
The persistence-class value specifies the name of your custom persistence class.
This class must implement the generated persistence interface or extend the
generated persistence class. This allows you to override default behavior
without modifying the generated persistence class.
You can generate classes to use a custom data source and session factory.
Point "spring.configs" in portal.properties to load your custom Spring XML with
the definitions of your custom data source and session factory. Then set the
data-source and session-factory values to your custom values.
The data-source value specifies the data source target that is set to the
persistence class. The default value is the Liferay data source. This is used in
conjunction with session-factory. See data-source-spring-professional.xml (or
data-source-spring-enterprise.xml).
The session-factory value specifies the session factory that is set to the
persistence class. The default value is the Liferay session factory. This is
used in conjunction with data-source. See data-source-spring-professional.xml
(or data-source-spring-enterprise.xml).
The tx-manager value specifies the transaction manager that Spring uses. The
default value is the Spring Hibernate transaction manager that wraps the Liferay
data source and session factory. See data-source-spring-professional.xml (or
data-source-spring-enterprise.xml).
-->
<!ATTLIST entity
name CDATA #REQUIRED
table CDATA #IMPLIED
local-service CDATA #IMPLIED
remote-service CDATA #IMPLIED
persistence-class CDATA #IMPLIED
data-source CDATA #IMPLIED
session-factory CDATA #IMPLIED
tx-manager CDATA #IMPLIED
>
<!--
The column element represents a column in the database.
-->
<!ELEMENT column (#PCDATA)>
<!--
The name value specifies the getter and setter name in the entity.
The type value specifies whether the column is a String, Boolean, or int, etc.
For example:
<column name="companyId" db-name="companyId" type="String" />
The above column specifies that there will be a getter called
pojo.getCompanyId() that will return a String.
Set db-name to map the field to a physical database column that is different
from the column name.
If the primary value is set to true, then this column is part of the primary key
of the entity. If multiple columns have the primary value set to true, then a
compound key will be created.
See com.liferay.portal.service.persistence.LayoutPK for an example of a compound
primary key.
If the entity and mapping-key attributes are specified and mapping-table is not,
then the Service Builder will assume you are specifying a one to many
relationship.
For example:
<column
name="shoppingItemPrices"
type="Collection"
entity="ShoppingItemPrice"
mapping-key="itemId"
/>
The above column specifies that there will be a getter called
pojo.getShoppingItemPrices() that will return a collection. It will map to a
column called itemId in the table that maps to the entity ShoppingItemPrice.
If the entity and mapping-table attributes are specified and mapping-key is not,
then the Service Builder will assume you are specifying a many to many
relationship.
For example:
<column
name="roles"
type="Collection"
entity="Role"
mapping-table="Groups_Roles"
/>
The above column specifies that there will be a getter called
pojo.getRoles() that will return a collection. It will use a mapping table
called Groups_Roles to give a many to many relationship between groups and
roles.
The id-type and id-param values are used in order to create an auto-generated,
auto-incrementing primary key when inserting records into a table. This can be
implemented in 4 different ways, depending on the type of database being used.
In all cases, the primary key of the model object should be assigned a value of
null, and Hibernate will know to replace the null value with an auto-generated,
auto-incremented value. If no id-type value is used, it is assumed that the
primary key will be assigned and not auto-generated.
The first implementation uses a class to generate a primary key.
For example:
<column
name="id"
type="Integer"
primary="true"
id-type="class"
id-param="com.liferay.counter.service.persistence.IDGenerator"
/>
In this implementation, the class specified in the id-param value will be called
to retrieve a unique identifier (in the example above, an Integer) that will be
used as the primary key for the new record. This implementation works for all
supported databases.
The second implementation generates identifiers that are unique only when no
other process is inserting data into the same table. This implementation should
NOT be used in a clustered environment, but it does work for all supported
databases.
For example:
<column
name="id"
type="Integer"
primary="true"
id-type="increment"
/>
The third implementation uses an identity column to generate a primary key.
For example:
<column
name="id"
type="Integer"
primary="true"
id-type="identity"
/>
In this implementation, the create table SQL generated for this entity will
create an identity column that natively auto-generates a primary key whenever
an insert occurs. This implementation is only supported by DB2, MySQL, and
MS SQL Server.
The fourth implementation uses a sequence to generate a primary key.
For example:
<column
name="id"
type="Integer"
primary="true"
id-type="sequence"
id-param="id_sequence"
/>
In this implementation, a create sequence SQL statement is created based on
the id-param value (stored in /sql/sequences.sql). This sequence is then
accessed to generate a unique identifier whenever an insert occurs. This
implementation is only supported by DB2, Oracle, PostgreSQL, and SAP DB.
The convert-null value specifies whether or not the column value is
automatically converted to a non null value if it is null. This only applies if
the type value is String. This is particularly useful if your entity is
referencing a read only table or a database view so that Hibernate does not try
to issue unnecessary updates. The default value is true.
-->
<!ATTLIST column
name CDATA #REQUIRED
db-name CDATA #IMPLIED
type CDATA #REQUIRED
primary CDATA #IMPLIED
entity CDATA #IMPLIED
mapping-key CDATA #IMPLIED
mapping-table CDATA #IMPLIED
id-type CDATA #IMPLIED
id-param CDATA #IMPLIED
convert-null CDATA #IMPLIED
>
<!--
The order element specifies a default ordering and sorting of the entities when
they are retrieved from the database.
-->
<!ELEMENT order (order-column+)>
<!--
Set the by attribute to "asc" or "desc" to order by ascending or descending.
-->
<!ATTLIST order
by CDATA #IMPLIED
>
<!--
The order-column element allows you to order the entities by specific columns.
-->
<!ELEMENT order-column (#PCDATA)>
<!--
The attributes of the order-column element allows you to fine tune the ordering
of the entity.
For example:
<order by="asc">
<order-column name="parentLayoutId" />
<order-column name="priority" />
</order>
The above settings will order by parentLayoutId and then by priority in an
ascending manner.
For example:
<order by="asc">
<order-column name="name" case-sensitive="false" />
</order>
The above settings will order by name and will not be case sensitive.
For example:
<order>
<order-column name="articleId" order-by="asc" />
<order-column name="version" order-by="desc" />
</order>
The above settings will order by articleId in an ascending manner and then by
version in a descending manner.
-->
<!ATTLIST order-column
name CDATA #REQUIRED
case-sensitive CDATA #IMPLIED
order-by CDATA #IMPLIED
>
<!--
The finder element represents a generated finder method.
-->
<!ELEMENT finder (finder-column+)>
<!--
-->
<!ATTLIST finder
name CDATA #REQUIRED
return-type CDATA #REQUIRED
where CDATA #IMPLIED
db-index CDATA #IMPLIED
>
<!--
The finder-column element specifies the columns to find by.
-->
<!ELEMENT finder-column (#PCDATA)>
<!--
The name value specifies the name of the finder method.
For example:
<finder name="CompanyId" return-type="Collection">
<finder-column name="companyId" />
</finder>
The above settings will create a finder with the name findByCompanyId that will
return a Collection and require a given companyId. It will also generate
several more findByCompanyId methods that take in pagination fields (int begin,
int end) and more sorting options. The easiest way to understand this is to
look at a generated PersistenceImpl class. The Service Builder will also
generate removeByCompanyId and countByCompanyId.
See com.liferay.portal.service.persistence.LayoutPersistenceImpl for a good
example.
The attribute comparator takes in the values =, !=, <, <=, >, >=, or LIKE and is
used to compare this column.
-->
<!ATTLIST finder-column
name CDATA #REQUIRED
db-name CDATA #IMPLIED
comparator CDATA #IMPLIED
>
<!--
The exceptions element contain a list of generated exceptions. This doesn't save
a lot of typing, but can still be helpful.
-->
<!ELEMENT exceptions (exception*)>
<!--
See the comments in exceptions element.
-->
<!ELEMENT exception (#PCDATA)>