The input from this article comes from:
Service builder principles
Service builder relies on forward engineering and a descriptive format of the model that complies with a dtd. So the user needs to create a valid xml file called service.xml.
Service xml main nodes are 'entity' node.
Entity node describe a persistence entity (i.e. table) for a RDBMS.
The entity description covers columns and relationships (parents and children via collection) as well as primary key strategy.
This file serves as input to an ant task that carries on the generation process. Some 20 different artifacts are generated. All of those artifacts are service-builder 'entity' node centric.
Service builder from a generation perspective
Forward-engineering
Is a approach domain centric as some advantages:
- density of the information (a simple file to describe)
Service builder from minuteproject perspective
Minuteproject is evolving from smart reverse-engineering to a development methodology platform focusing on 4 Weapons of Mass Productivity:
- smart reverse-engineering
- virtualization
- statement driven development (SDD)
- transient definition
Service builder / Minuteproject matching
Although the philosophies (forward-engineering vs. reverse-engineering) are different there is a mapping between the both approach.
The question is are all the information in service builder available by minuteproject reverse-engineering?
YES!
Let's have a element review of service builder nodes
Service builder
<
ATTLIST service-builder
package-path CDATA #REQUIRED
auto-namespace-tables CDATA #IMPLIED
>
<!ELEMENT author (#PCDATA)>
<!ELEMENT namespace (#PCDATA)
>
package-path, author, namespace can be deduced by minuteproject model node
Entity
<
ATTLIST entity
name CDATA #REQUIRED
human-name CDATA #IMPLIED
table CDATA #IMPLIED
uuid CDATA #IMPLIED
uuid-accessor 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
cache-enabled CDATA #IMPLIED
json-enabled CDATA #IMPLIED
>
Entity name can be deduced from table name (or view name)
Human name can be deduce by table alias name
All the other boolean field can be deduce by so convention or some parameters to set on the mp4liferay track
Datasource can be deduced by convention (related to the namespace) (and also generated by MP)
Column
<!ATTLIST column
name CDATA #REQUIRED
db-name CDATA #IMPLIED
type CDATA #REQUIRED
primary CDATA #IMPLIED
accessor CDATA #IMPLIED
filter-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
lazy CDATA #IMPLIED
localized CDATA #IMPLIED
json-enabled CDATA #IMPLIED
>
Column info can be found by reverse-engineering name (via alias), db-name, type, primary, entity, mapping-key, mapping-table.Id-type and id-param can be deduced from the PK strategy associated to the database type.
MP covers those described in service.xml (uuid, sequence, autoincrement, identity)
Finder and finder-column
can be deduce from defaulting (pk, fk) or with the semantic reference of the table.
References correspond to DB relationships.
Review conclusion
This means that the main information can be deduced from the smart reverse-engineering.What is missing can be added by convention a liferay configuration for defaulting (such as companyId, groupId, finder extra info) and parametrization of the liferay track.
In all the case the configuration of service.xml (generated by MP) can be manually changed and at the next generation from the DB your alterations are kept!! Thank to updatable code feature of MP.
Can minuteproject even extend service-builder facility?
YES AGAIN!
Virtualization
This is the strong point of reverse-engineering: you can work with Views. In forward-engineering it is impossible since you cannot guess the implementation whereas in reverse-engineering, you take it as is!
So your view can be set as entity in service.xml (with readonly access)
But what is the identity field of this view. Minuteproject enrichment or convention enable to grant one to a field acting as a unique key.
Even better, minuteproject provides you the ability to grant relationships between view like parent-child foreign key and this can also be used in service.xml
Enrichment
Example: detect relationship between entity when no foreign key present.
Can minuteproject do more for service builder?
YES!
Validation - mandatory and type are not enough
You should have stereotype such as email, url, password. A stereotype is an abstraction between presentation and validation aspects.
Constraints
Limit the column value to a enumeration.
Updatable code
The code you generate can be updated via some extension points. The next time you generate your modification are kept!
Datasource
Minuteproject can generate the datasource code
Semantic reference
Sometimes you do not want to display the entire entity fields but just the more important. This is the semantic reference.
Work with Statement only
Sometimes you can go back to the fundamentals of your UCs (I/O + function).
Ex a jdbc call to a stored procedure.
DTO oriented service
The input is not mapped to a persistence entity.
Conclusion
After this feasability review, minuteproject can have the capabilities to generate service.xml of liferay from the DB. But also to extend it.
A sample generation is foreseen for MP release 0.8.5.
The first approach is to generate the SB input configuration. But nearly all generated artifacts SB generate can also be generated by MP.
A sample generation is foreseen for MP release 0.8.5.
The first approach is to generate the SB input configuration. But nearly all generated artifacts SB generate can also be generated by MP.
