gnue/appserver/doc/whitepaper version.texi whit...

[Reinhard Mueller]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Reinhard Mueller <address@hidden>       02/06/03 05:44:11

Modified files:
        appserver/doc/whitepaper: version.texi whitepaper.texi 

Log message:
        Changed the word "field" to "attribute" if it related to objects, and 
to "column" if it related to databases.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/appserver/doc/whitepaper/version.texi.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/appserver/doc/whitepaper/whitepaper.texi.diff?tr1=1.4&tr2=1.5&r1=text&r2=text

Patches:
Index: gnue/appserver/doc/whitepaper/version.texi
diff -c gnue/appserver/doc/whitepaper/version.texi:1.4 
gnue/appserver/doc/whitepaper/version.texi:1.5
*** gnue/appserver/doc/whitepaper/version.texi:1.4      Thu May 23 12:08:14 2002
--- gnue/appserver/doc/whitepaper/version.texi  Mon Jun  3 05:44:11 2002
***************
*** 1,2 ****
! @set UPDATED 2002-05-23
! @set EDITION 0.0.6
--- 1,2 ----
! @set UPDATED 2002-06-03
! @set EDITION 0.0.7
Index: gnue/appserver/doc/whitepaper/whitepaper.texi
diff -c gnue/appserver/doc/whitepaper/whitepaper.texi:1.4 
gnue/appserver/doc/whitepaper/whitepaper.texi:1.5
*** gnue/appserver/doc/whitepaper/whitepaper.texi:1.4   Thu May 23 12:08:14 2002
--- gnue/appserver/doc/whitepaper/whitepaper.texi       Mon Jun  3 05:44:11 2002
***************
*** 130,209 ****
  on the entity is called a @dfn{business object}.
  
  GEAS lets the user define @dfn{classes} of business objects. The class
! definitions describe both the data elements (called @dfn{fields}) and the
  available functions (called @dfn{methods}) of the business object.
  
  The specific incarnation of a business object (for example a specific 
customer)
  is called a business object @dfn{instance}.
  
! @section Fields
  
! GEAS will provide the following field types:
  
  @table @dfn
! @item Basic fields
! contain most of the actual information, in the basic field types @dfn{string},
! @dfn{number}, @dfn{datetime}, and @dfn{boolean}. Examples could contain
! customer name, item price, invoice date, and invoice payment status.
! 
! @item Compound fields
! are a means for combining fields that logically belong together and appear
! repeatedly in the same combination. Compound fields can be built from fields
! of any type, not only of basic fields. An example could be a monetary value
! consisting of the amount and the currency.
  
! @item Reference fields
  point to another object and declare a relation between two objects. The value
! of a reference field is another object. Examples include the customer of an
  invoice or the preferred vendor of an item.
  
! @item List fields
  point to lists of objects and declare a relation between these objects. The
! value of a list field is a list of objects of a defined class, where all
  objects in the list will be of the same class. Examples include all line items
  of an invoice, or all contact persons of a customer.
  
! @item Calculated fields
! contain information that is generated by GEAS out of other fields. Calculated
! fields are generally read-only. An example could be the total value of an
! invoice item (calculated from price * pieces) or the total value of an
! invoice (calculated from all total item values).
! 
! @item Indirect fields
! are fields of a referenced object and can be accessed as if they were fields
! of the current object. Examples could include the name of the customer of the
! invoice, or the name of the preferred vendor of the item of an invoice line
! item.
  @end table
  
  @section Methods
  
  A method is code performed on an object. Methods can have parameters of any
! field type (string, number, reference, etc.). Every method has the paramter
  @dfn{self}, that is the object instance to operate on, as a parameter.
  
  @section Modules
  
! Modules define namespaces for classes, fields and methods. When module A
! defines a class and some fields and methods for the class, module B can
! extend the class with new fields. Another module C can independently
! extend the class, without taking care about not using the same field names
  as module B, because all modules have their own namespace.
  
! @section Qualified class, field and method names
  
  @emph{Note: This section is absolutely subject to discussion. We are looking 
for
  a good and understandable syntax for fully qualified names.}
  
! Class, field and method names can be preceded by a module name to override
  the current module context. In this case, the module name is separated by a
  colon (:).
  
! Compound field names can be followed with a dot (.) and a member name of the
  compound.
  
! Reference field names can be followed with a dot (.) and a field name of the
! referenced object to form an indirect field.
  
  Example:
  
--- 130,210 ----
  on the entity is called a @dfn{business object}.
  
  GEAS lets the user define @dfn{classes} of business objects. The class
! definitions describe both the data elements (called @dfn{attributes}) and the
  available functions (called @dfn{methods}) of the business object.
  
  The specific incarnation of a business object (for example a specific 
customer)
  is called a business object @dfn{instance}.
  
! @section Attributes
  
! GEAS will provide the following attribute types:
  
  @table @dfn
! @item Basic attributes
! contain most of the actual information, in the basic attribute types
! @dfn{string}, @dfn{number}, @dfn{datetime}, and @dfn{boolean}. Examples
! could contain customer name, item price, invoice date, and invoice payment
! status.
! 
! @item Compound attributes
! are a means for combining attributes that logically belong together and appear
! repeatedly in the same combination. Compound attributes can be built from
! attributes of any type, not only of basic attributes. An example could be a
! monetary value consisting of the amount and the currency.
  
! @item Reference attributes
  point to another object and declare a relation between two objects. The value
! of a reference attribut is another object. Examples include the customer of an
  invoice or the preferred vendor of an item.
  
! @item List attributes
  point to lists of objects and declare a relation between these objects. The
! value of a list attributes is a list of objects of a defined class, where all
  objects in the list will be of the same class. Examples include all line items
  of an invoice, or all contact persons of a customer.
  
! @item Calculated attributes
! contain information that is generated by GEAS out of other attributes.
! Calculated attributes are generally read-only. An example could be the total
! value of an invoice item (calculated from price * pieces) or the total value
! of an invoice (calculated from all total item values).
! 
! @item Indirect attributes
! are attributes of a referenced object and can be accessed as if they were
! attributes of the current object. Examples could include the name of the
! customer of the invoice, or the name of the preferred vendor of the item of
! an invoice line item.
  @end table
  
  @section Methods
  
  A method is code performed on an object. Methods can have parameters of any
! attribute type (string, number, reference, etc.). Every method has the 
paramter
  @dfn{self}, that is the object instance to operate on, as a parameter.
  
  @section Modules
  
! Modules define namespaces for classes, attributes, and methods. When module A
! defines a class and some attribute and methods for the class, module B can
! extend the class with new attributes. Another module C can independently
! extend the class, without taking care about not using the same attribute names
  as module B, because all modules have their own namespace.
  
! @section Qualified class, attribute and method names
  
  @emph{Note: This section is absolutely subject to discussion. We are looking 
for
  a good and understandable syntax for fully qualified names.}
  
! Class, attribute and method names can be preceded by a module name to override
  the current module context. In this case, the module name is separated by a
  colon (:).
  
! Compound attribute names can be followed with a dot (.) and a member name of 
the
  compound.
  
! Reference attribute names can be followed with a dot (.) and a attribute name
! of the referenced object to form an indirect attribute.
  
  Example:
  
***************
*** 215,256 ****
  customer class, and @code{sales:invoice_head} is the fully referenced class
  name for the invoice_head class.
  
! Now, let module "cust" define the fields "name" and "address" for the
! customer class, where address is a compound field consisting of "street"
  and "city".
  
! The following are now valid field references of a customer object:
  
! @code{name} or @code{cust:name} is a base field.
  
! @code{address} or @code{cust:address} is a compound field.
  
! @code{address.street} or @code{cust:address.street} is a compound member 
field.
  
! Now, the module "sales" extends the customer class by a field "last_invoice"
  which is a reference to an invoice_head object.
  
  @code{sales:last_invoice} is a reference containing an invoice_head object.
  
! If module "sales" defines the fields "number" and "items" in "invoice_header",
! then
  
! @code{sales:last_invoice.number} is an indirect field and
  
! @code{sales:last_invoice.items} is an indirect field, which is a list field.
  
  And if yet another module "acct" extends the invoice_header class by a
! field "paid", then
  
! @code{sales:last_invoice.acct:paid} could be a boolean field that tells you
  whether the customer has paid his last invoice or not, and you would access
! it just as easy as the "name" field. However, this field would only be
  available if all three modules "cust", "sales", and "acct" are installed.
  
  @section Triggers
  
  @dfn{Triggers} are methods that are automatically called upon occurance of
! defined @dfn{events}, for example on every change of a specific field,
  or before a commit of a changed object.
  
  Triggers are always methods of the object where the event occurs. Because
--- 216,259 ----
  customer class, and @code{sales:invoice_head} is the fully referenced class
  name for the invoice_head class.
  
! Now, let module "cust" define the attributes "name" and "address" for the
! customer class, where address is a compound attribute consisting of "street"
  and "city".
  
! The following are now valid attribute references of a customer object:
  
! @code{name} or @code{cust:name} is a base attribute.
  
! @code{address} or @code{cust:address} is a compound attribute.
  
! @code{address.street} or @code{cust:address.street} is a compound member
! attribute.
  
! Now, the module "sales" extends the customer class by a attribute 
"last_invoice"
  which is a reference to an invoice_head object.
  
  @code{sales:last_invoice} is a reference containing an invoice_head object.
  
! If module "sales" defines the attribute "number" and "items" in
! "invoice_header", then
  
! @code{sales:last_invoice.number} is an indirect attribute and
  
! @code{sales:last_invoice.items} is an indirect attribute, which is a list
! attribute.
  
  And if yet another module "acct" extends the invoice_header class by a
! attribute "paid", then
  
! @code{sales:last_invoice.acct:paid} could be a boolean attribute that tells 
you
  whether the customer has paid his last invoice or not, and you would access
! it just as easy as the "name" attribute. However, this attribute would only be
  available if all three modules "cust", "sales", and "acct" are installed.
  
  @section Triggers
  
  @dfn{Triggers} are methods that are automatically called upon occurance of
! defined @dfn{events}, for example on every change of a specific attribute,
  or before a commit of a changed object.
  
  Triggers are always methods of the object where the event occurs. Because
***************
*** 268,274 ****
  will be @code{sales:OnChangeName} and therefore different from the other
  method.
  
! If the field "Name" is changed in a customer object, GEAS would call both
  methods because both are named "OnChangeName". The order of the method calls
  would be unpredictable.
  
--- 271,277 ----
  will be @code{sales:OnChangeName} and therefore different from the other
  method.
  
! If the attribute "Name" is changed in a customer object, GEAS would call both
  methods because both are named "OnChangeName". The order of the method calls
  would be unpredictable.
  
***************
*** 351,362 ****
  all without SQL.
  
  Eventually, GEDI will support creating and extending tables "on the fly",
! which means that reading a recordset with fields that don't exist in the
! database will automagically add the missing fields to the table.  This
  will of course be parameterized.
  
  GEDI operates strictly on a table/row interface and doesn't know anything
! about object, fields and methods.
  
  GEDI actually consists of two mostly independent parts, the Database Adapter
  and the SQL generator.
--- 354,365 ----
  all without SQL.
  
  Eventually, GEDI will support creating and extending tables "on the fly",
! which means that reading a recordset with attributes that don't exist in the
! database will automagically add the missing columns to the table.  This
  will of course be parameterized.
  
  GEDI operates strictly on a table/row interface and doesn't know anything
! about object, attributes and methods.
  
  GEDI actually consists of two mostly independent parts, the Database Adapter
  and the SQL generator.
***************
*** 390,396 ****
  
  @section GNU Enterprise Object Repository (GEOR)
  
! GEOR will hold all the business object definitions: what fields the object
  consists of, what methods exist, which triggers should be called on what
  event, and so on.
  
--- 393,399 ----
  
  @section GNU Enterprise Object Repository (GEOR)
  
! GEOR will hold all the business object definitions: what attributes the object
  consists of, what methods exist, which triggers should be called on what
  event, and so on.