From 3ea96e753be7a62d956d2be2be83679a96ffbee5 Mon Sep 17 00:00:00 2001
From: Johannes Hoermann <j.hoermann@adito.de>
Date: Mon, 3 Dec 2018 11:32:52 +0100
Subject: [PATCH] refactor readme's
---
others/db_changes/readme.adoc | 172 +++++++++++-----------
others/guide/how to write JDito code.adoc | 9 +-
2 files changed, 90 insertions(+), 91 deletions(-)
diff --git a/others/db_changes/readme.adoc b/others/db_changes/readme.adoc
index 4763f6c404..0a3669f7ce 100644
--- a/others/db_changes/readme.adoc
+++ b/others/db_changes/readme.adoc
@@ -1,87 +1,87 @@
-liquibase-readme
-================
-
-== Structure within ADITO
-=== in theory
-
-When using liquibase in an ADITO-System, your project structure _should_ look like this:
-----
-PROJECTHOME/others/db_changes/masterChangelog.xml
-PROJECTHOME/others/db_changes/struct/
-PROJECTHOME/others/db_changes/data/
-PROJECTHOME/others/db_changes/misc/
-PROJECTHOME/others/db_changes/liquibase.properties
-----
-
-The file `masterChangelog.xml` contains a list of all changes (well, in fact more like a list of all changelog-files). The structure could look like this:
-[source,xml]
-----
-<?xml version="1.1" encoding="UTF-8" standalone="no"?>
-<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.6.xsd">
- <include file="struct/create_org.xml"/>
- <include file="data/example_org.xml"/>
-</databaseChangeLog>
-----
-
-TIP: Keep in mind that the header-information can change, visit therefore the liquibase-website: http://www.liquibase.org Specific: the XML-format definition: http://www.liquibase.org/documentation/xml_format.html
-
-So, thats where all our changes are located - but what about the changes _itself_?
-As you can think of, they're stored in files located in the folders `struct` for DDL-stuff like _create_, _alter_ etc.
-and `data` for DML-stuff like _insert_, _update_ etc.
-
-If you want to know what to do add in these files take a look at the official liquibase documentation for futher information how to fill these XML files: http://www.liquibase.org/documentation/index.html
-
-IMPORTANT: Always remember that you might have to define some rollback-entries. +
-This is e.g. not needed for create-entries but for others like insert.
-
-So, whats about that `liquibase.properties` file? The file is needed to specify some data here, e.g. the driver-name, classpath (of the driver), jdbc-url, etc.
-You want to store these information there because otherwise you'd need to specify them on every call of liquibase. Not cool.
-
-Now you're ready to run commands like `liquibase update` in the `PROJECTHOME/others/db_changes` folder.
-
-=== in practice
-
-.Let's say whe want to add a new table `FOOBAR` with some demo-data. We need to:
-* create a new file in the struct-folder; e.g. `create_FOOBAR.xml`
-* fill the file with changesets that will create a table
-* add `include`-tag in the `masterChangelog.xml` for the created file
-* create a new file in the data-foler; e.g. `demoData_FOOBAR.xml`
-* fill the file with changesets that will insert data into the table and define *rollback-entries*
-* add `include`-tag in the `masterChangelog.xml` for the created file
-* to apply the changes simply run `liquibase update`
-
-For example one featurepackage "add contact management" could contain several files itself:
-----
- create_org.xml
- create_pers.xml
- create_relation.xml
-----
-On the other hand, several featurepackages cannot be contained in one changelog-file.
-
-
-== How to use it
-Normally everything you need is provided by the project-template and the existing files in the git-repository.
-Therefore it's easy to use and you can start immediately.
-
-.Keep in mind:
-* run `liquibase update` to apply possible changes after merging something into your repository
-* apply modifications on the database always with liquibase; do not write a create-script in SQL. Write some changesets and execute them
-* set correct `author`- and `id`-attributes in your changelog-files
-
-
-
-== FAQ
-[qanda]
-What about unicode-columns like `NVARCHAR` or `NCLOB`?::
- Simply define them in your changesets; This is something which is not completely verified:
- Maybe columns like `NCLOB` cause problems in some DBMS like _MS SQL Server_
-What if i swtich between branches and want to switch between different database-states?::
- This is something that needs to be defined. Possible ways: rollback or recreate your database entirely
-Is it possible to write an update-changeset where I can use a preparedStatement in the where-clause?::
- This needs to be analysed and (the result) added here.
-
-
-
----
-
+liquibase-readme
+================
+
+== Structure within ADITO
+=== in theory
+
+When using liquibase in an ADITO-System, your project structure _should_ look like this:
+----
+PROJECTHOME/others/db_changes/masterChangelog.xml
+PROJECTHOME/others/db_changes/struct/
+PROJECTHOME/others/db_changes/data/
+PROJECTHOME/others/db_changes/misc/
+PROJECTHOME/others/db_changes/liquibase.properties
+----
+
+The file `masterChangelog.xml` contains a list of all changes (well, in fact more like a list of all changelog-files). The structure could look like this:
+[source,xml]
+----
+<?xml version="1.1" encoding="UTF-8" standalone="no"?>
+<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.6.xsd">
+ <include file="struct/create_org.xml"/>
+ <include file="data/example_org.xml"/>
+</databaseChangeLog>
+----
+
+TIP: Keep in mind that the header-information can change, visit therefore the liquibase-website: http://www.liquibase.org Specific: the XML-format definition: http://www.liquibase.org/documentation/xml_format.html
+
+So, that's where all our changes are located - but what about the changes _itself_?
+As you can think of, they're stored in files located in the folders `struct` for DDL-stuff like _create_, _alter_ etc.
+and `data` for DML-stuff like _insert_, _update_ etc.
+
+If you want to know what to do add in these files take a look at the official liquibase documentation for futher information how to fill these XML files: http://www.liquibase.org/documentation/index.html
+
+IMPORTANT: Always remember that you might have to define some rollback-entries. +
+This is e.g. not needed for create-entries but for others like insert.
+
+So, whats about that `liquibase.properties` file? The file is needed to specify some data here, e.g. the driver-name, classpath (of the driver), jdbc-url, etc.
+You want to store these information there because otherwise you'd need to specify them on every call of liquibase. Not cool.
+
+Now you're ready to run commands like `liquibase update` in the `PROJECTHOME/others/db_changes` folder.
+
+=== in practice
+
+.Let's say we want to add a new table `FOOBAR` with some demo-data. We need to:
+* create a new file in the struct-folder; e.g. `create_FOOBAR.xml`
+* fill the file with changesets that will create a table
+* add `include`-tag in the `masterChangelog.xml` for the created file
+* create a new file in the data-foler; e.g. `demoData_FOOBAR.xml`
+* fill the file with changesets that will insert data into the table and define *rollback-entries*
+* add `include`-tag in the `masterChangelog.xml` for the created file
+* to apply the changes simply run `liquibase update`
+
+For example one feature package "add contact management" could contain several files itself:
+----
+ create_org.xml
+ create_pers.xml
+ create_relation.xml
+----
+On the other hand, several feature packages cannot be contained in one changelog-file.
+
+
+== How to use it
+Normally everything you need is provided by the project-template and the existing files in the git-repository.
+Therefore it's easy to use and you can start immediately.
+
+.Keep in mind:
+* run `liquibase update` to apply possible changes after merging something into your repository
+* apply modifications on the database always with liquibase; do not write a create-script in SQL. Write some changesets and execute them
+* set correct `author`- and `id`-attributes in your changelog-files
+
+
+
+== FAQ
+[qanda]
+What about unicode-columns like `NVARCHAR` or `NCLOB`?::
+ Simply define them in your changesets; This is something which is not completely verified:
+ Maybe columns like `NCLOB` cause problems in some DBMS like _MS SQL Server_
+What if i switch between branches and want to switch between different database-states?::
+ This is something that needs to be defined. Possible ways: rollback or recreate your database entirely
+Is it possible to write an update-changeset where I can use a preparedStatement in the where-clause?::
+ This needs to be analyzed and (the result) added here.
+
+
+
+---
+
~have~ ~a~ ~nice~ ~day~ ~:-)~
\ No newline at end of file
diff --git a/others/guide/how to write JDito code.adoc b/others/guide/how to write JDito code.adoc
index 7f4e9bdabf..aacf74650d 100644
--- a/others/guide/how to write JDito code.adoc
+++ b/others/guide/how to write JDito code.adoc
@@ -74,14 +74,13 @@ Definition:
* @static
* @class
*/
-function CommValidationUtil(){<1>
-}
+function CommValidationUtil(){}<1>
/**
* returns a blueprint for validation extensions; these extensions are needed for validating comm data and can be passed to other functions
* @return {object} a object with properties that have a specific default value; normally you want to overwrite that value
*/
-CommValidationUtil.getExtensionsBlueprint = function(){<2>
+CommValidationUtil.getExtensionsBlueprint = function() {<2>
return {
countryCode: null
};
@@ -114,7 +113,7 @@ Definition:
* @param {String} [alias=the current alias] the database alias where the condition shall be executed later (important for column types of preparedStatements) <2>
* @example //TODO: add missing example <3>
*/
-function SqlCondition(alias){<4>
+function SqlCondition(alias) {<4>
//setting null is only needed to provide autocomplete for the ADITO-designer
this.preparedValues = null;
this._init();//the properties are initalized in an extra function because init is nearly the same as resetting (clearing) the SqlConditions
@@ -125,7 +124,7 @@ function SqlCondition(alias){<4>
* @param {String} cond the condition string which shall be appended
* @return {Object} current SqlCondition-object
*/
-SqlCondition.prototype.and = function(cond){<5>
+SqlCondition.prototype.and = function(cond) {<5>
if (!cond)
return this;
if (this._sqlStorage)
--
GitLab