r6515 - trunk/gnue-appserver/doc/devguide

[reinhard]

Author: reinhard
Date: 2004-10-19 09:39:28 -0500 (Tue, 19 Oct 2004)
New Revision: 6515

Modified:
   trunk/gnue-appserver/doc/devguide/02-concepts.texi
   trunk/gnue-appserver/doc/devguide/03-basicdb.texi
   trunk/gnue-appserver/doc/devguide/04-ui.texi
   trunk/gnue-appserver/doc/devguide/devguide.texi
Log:
Macro didn't work as I expected.


Modified: trunk/gnue-appserver/doc/devguide/02-concepts.texi
===================================================================
--- trunk/gnue-appserver/doc/devguide/02-concepts.texi  2004-10-19 11:36:26 UTC 
(rev 6514)
+++ trunk/gnue-appserver/doc/devguide/02-concepts.texi  2004-10-19 14:39:28 UTC 
(rev 6515)
@@ -17,38 +17,40 @@
 the database server, usually based on SQL, which was hard to learn and very
 limited in its possibilities.
 
-With @GNUe, we use an application server to handle both the data storage and
-the logic.  While it delegates most of the data storage tasks to a classic SQL
-database backend, it lets you define the underlying logic by writing program
-code in Python, a very powerful yet easy to learn language.
+With GNU Enterprise, we use an application server to handle both the data
+storage and the logic.  While it delegates most of the data storage tasks to a
+classic SQL database backend, it lets you define the underlying logic by
+writing program code in Python, a very powerful yet easy to learn language.
 
-In @GNUe, a database table and the related program code form a logical unit
-called a @dfn{class}.  A typical example for a class would be @samp{customer},
-being composed of a database table with columns like @samp{name},
address@hidden, and @samp{city}, and several pieces of program code defining
-things like under which conditions the customer may receive goods, how an
-address label has to be printed, what makes up a correct and complete customer
-record at all, or under which conditions the customer may be deleted from the
-database.
+In GNU Enterprise, a database table and the related program code form a logical
+unit called a @dfn{class}.  A typical example for a class would be
address@hidden, being composed of a database table with columns like
address@hidden, @samp{street}, and @samp{city}, and several pieces of program 
code
+defining things like under which conditions the customer may receive goods, how
+an address label has to be printed, what makes up a correct and complete
+customer record at all, or under which conditions the customer may be deleted
+from the database.
 
-To distinguish between the database layer and the @GNUe@ layer, we speak of
address@hidden, and @dfn{columns} for the database, and of @dfn{classes},
address@hidden, and @dfn{procedures} for the stuff we do in @GNUe.
+To distinguish between the database layer and the GNU Enterprise layer, we
+speak of @dfn{tables}, and @dfn{columns} for the database, and of
address@hidden, @dfn{properties}, and @dfn{procedures} for the stuff we do in
+GNU Enterprise.
 
 If you have ever dealt with object oriented programming, the word @emph{class}
 probably rings a bell for you.  But please be aware: although classes in
address@hidden@ share some aspects of object oriented programming (like the 
association
-of code with data or some kind of polymorphism), there are still some important
-differences.  Most notably, @GNUe@ classes don't support inheritance.
+GNU Enterprise share some aspects of object oriented programming (like the
+association of code with data or some kind of polymorphism), there are still
+some important differences.  Most notably, GNU Enterprise classes don't support
+inheritance.
 
 
 @section Modules
 
-One of the main design goals of @GNUe@ was to be @emph{modular}.  Several
-authors should be able to develop applications independently of each other, and
-these applications should be able to work together smoothly.  To reach this
-goal, it was necessary to introduce a concept of @dfn{namespaces} so that class
-names can't collide.
+One of the main design goals of GNU Enterprise was to be @emph{modular}.
+Several authors should be able to develop applications independently of each
+other, and these applications should be able to work together smoothly.  To
+reach this goal, it was necessary to introduce a concept of @dfn{namespaces} so
+that class names can't collide.
 
 Usually, a set of classes that is usually used together is put into the same
 namespace, maintained by the same author (or group of authors) and installed
@@ -64,12 +66,12 @@
 
 @section Class Extension
 
-As mentioned above, @GNUe@ classes doesn't support the concept of inheritance.
-However, often a new module might want to change the behaviour of an existing
-class.  Given our above example, the "invoicing" module would not want to
-simple use the "item" class of the "stock" module, but it would want to add a
-rule to that class to make sure that, say, an item can't be deleted when it has
-been used in an invoice.
+As mentioned above, GNU Enterprise classes doesn't support the concept of
+inheritance.  However, often a new module might want to change the behaviour of
+an existing class.  Given our above example, the "invoicing" module would not
+want to simple use the "item" class of the "stock" module, but it would want to
+add a rule to that class to make sure that, say, an item can't be deleted when
+it has been used in an invoice.
 
 Using @dfn{class extension}, a module can not only reuse a class of another
 module, it can also change the behaviour of that class by adding new properties

Modified: trunk/gnue-appserver/doc/devguide/03-basicdb.texi
===================================================================
--- trunk/gnue-appserver/doc/devguide/03-basicdb.texi   2004-10-19 11:36:26 UTC 
(rev 6514)
+++ trunk/gnue-appserver/doc/devguide/03-basicdb.texi   2004-10-19 14:39:28 UTC 
(rev 6515)
@@ -13,7 +13,7 @@
 
 @section General GCD Layout
 
-To define the classes for @GNUe, we use @dfn{GCD files} (@GNUe@ class
+To define the classes for GNU Enterprise, we use @dfn{GCD files} (GNUe class
 definition files).  These files are a specialized XML file format.  You can
 write GCD files with any editor you want.
 
@@ -35,22 +35,23 @@
 @section Using GCD Files
 
 After having written the above GCD file, save it as @samp{address.gcd}.  Now we
-have to make @GNUe@ read and process our class definition.  We do this by
-typing
+have to make GNU Enterprise read and process our class definition.  We do this
+by typing
 @example
 gnue-readgcd address.gcd
 @end example
 @noindent
-at the command prompt.  This will teach @GNUe@ about our new class and make the
-database backend create the tables necessary to hold the data of this class.
+at the command prompt.  This will teach GNU Enterprise about our new class and
+make the database backend create the tables necessary to hold the data of this
+class.
 
 Please note that some databases don't allow adding new tables while there is an
 active connection to the database server, so you might have to kill the
 application server before entering the above command and restart it afterwards
 (this might be fixed in future).
 
-Now, as @GNUe@ has learned about our class, we are ready to display a form and
-enter data: type
+Now, as GNU Enterprise has learned about our class, we are ready to display a
+form and enter data: type
 @example
 gnue-forms appserver://appserver/form/address_person
 @end example
@@ -147,7 +148,7 @@
 
 @section Data Types
 
address@hidden@ supports the following basic data types:
+GNU Enterprise supports the following basic data types:
 
 @table @code
 @item string
@@ -172,9 +173,10 @@
 
 @item time
 This stores an absolute time value and is heavily dependent on the database
-backend.  Future versions of GNUe might have features to unify the handling of
-time values for the different databases, but until then, time properties are
-not recommended.  Neither length nor scale may be given for time properties.
+backend.  Future versions of GNU Enterprise might have features to unify the
+handling of time values for the different databases, but until then, time
+properties are not recommended.  Neither length nor scale may be given for time
+properties.
 
 @item datetime
 Datetime properties store a date and a time, often also called a

Modified: trunk/gnue-appserver/doc/devguide/04-ui.texi
===================================================================
--- trunk/gnue-appserver/doc/devguide/04-ui.texi        2004-10-19 11:36:26 UTC 
(rev 6514)
+++ trunk/gnue-appserver/doc/devguide/04-ui.texi        2004-10-19 14:39:28 UTC 
(rev 6515)
@@ -10,13 +10,14 @@
 
 @section General GLD Layout
 
address@hidden@ can use a lot of information from our class definition to build 
a form
-usable for entering data into that class. However, some decisions cannot be
-based on the class definition, most notably a good decision about field order
-and about labels to display.
+GNU Enterprise can use a lot of information from our class definition to build
+a form usable for entering data into that class. However, some decisions cannot
+be based on the class definition, most notably a good decision about field
+order and about labels to display.
 
-For that purpose, we have a second file type in @GNUe: @dfn{GLD files} (@GNUe@
-layout definition files). Like GCD files, they are a specialized form of XML.
+For that purpose, we have a second file type in GNU Enterprise: @dfn{GLD files}
+(GNUe language definition files). Like GCD files, they are a specialized form
+of XML.
 
 Let's create a GLD file matching our example:
 
@@ -36,20 +37,20 @@
 @section Using GLD Files
 
 After having written the above GLD file, save it as @samp{address-C.gld}.  Like
-for GCD files, there's a command to read GLD files into @GNUe:
+for GCD files, there's a command to read GLD files into GNU Enterprise:
 @example
 gnue-readgld address-C.gcd
 @end example
 
-Now we can see how @GNUe@ displays a much nicer form:
+Now we can see how GNU Enterprise displays a much nicer form:
 @example
 gnue-forms appserver://appserver/form/address_person
 @end example
 
-However, maybe English isn't your native language, and you want @GNUe@ to
-display the form with translated labels.  No problem: just create a second
+However, maybe English isn't your native language, and you want GNU Enterprise
+to display the form with translated labels.  No problem: just create a second
 file, for example @samp{address-de.gld} for German texts, exchange all labels
-with their respective translation, and read that into @GNUe, too.
+with their respective translation, and read that into GNU Enterprise, too.
 
 Now, users will be presented with the interface according to their own locale
 setting.

Modified: trunk/gnue-appserver/doc/devguide/devguide.texi
===================================================================
--- trunk/gnue-appserver/doc/devguide/devguide.texi     2004-10-19 11:36:26 UTC 
(rev 6514)
+++ trunk/gnue-appserver/doc/devguide/devguide.texi     2004-10-19 14:39:28 UTC 
(rev 6515)
@@ -4,14 +4,10 @@
 @include version.texi
 @setcontentsaftertitlepage
 
address@hidden GNUe
-GNU Enterprise
address@hidden macro
-
 @c ----------------------------------------------------------------------------
 
 @ifnottex
address@hidden @GNUe - Application Developer's Guide
address@hidden GNU Enterprise - Application Developer's Guide
 
 Edition @value{EDITION}, @value{UPDATED}
 
@@ -30,7 +26,7 @@
 @c ----------------------------------------------------------------------------
 
 @titlepage
address@hidden @GNUe
address@hidden GNU Enterprise
 @subtitle Application Developer's Guide
 @subtitle Edition @value{EDITION}, @value{UPDATED}
 @author Reinhard M@"uller