modeling-cvs

[<sbi...@us...>]

Update of /cvsroot/modeling/ProjectModeling/Modeling/doc/UserGuide
In directory sc8-pr-cvs1:/tmp/cvs-serv7657/doc/UserGuide

Modified Files:
	DefiningaModel.tex 
Log Message:
Re-introduced documentation for PyModel, by Mario

Index: DefiningaModel.tex
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/doc/UserGuide/DefiningaModel.tex,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** DefiningaModel.tex	4 Jul 2003 17:05:14 -0000	1.11
--- DefiningaModel.tex	17 Jul 2003 13:49:32 -0000	1.12
***************
*** 16,21 ****
  The next section reviews the main concepts of Entity-Relationship Modeling, 
  with the rest of the chapter dedicated to how such models map onto
! %the python description, or PyModel, and 
! the XML description. 
  
   Some included tools may help you with the design and management of 
--- 16,20 ----
  The next section reviews the main concepts of Entity-Relationship Modeling, 
  with the rest of the chapter dedicated to how such models map onto
! the python description, or PyModel, and the XML description. 
  
   Some included tools may help you with the design and management of 
***************
*** 23,28 ****
   command-line scripts. Thus, the easiest way to define a model would be to use the 
   ZModelizationTool inside a Zope instance. However, you do not {\em need} a 
!  Zope instance to design models, as %both PyModels and 
! XML models may be
   designed in your favorite editor.
   Both tools includes some validation logic, so that
--- 22,26 ----
   command-line scripts. Thus, the easiest way to define a model would be to use the 
   ZModelizationTool inside a Zope instance. However, you do not {\em need} a 
!  Zope instance to design models, as both PyModels and XML models may be
   designed in your favorite editor.
   Both tools includes some validation logic, so that
***************
*** 105,182 ****
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
! %\section{PyModels}
! %
! %A PyModel is a python module that defines a variable \var{model} 
! %that is of type \var{Model}. Objects of type \var{Model} collect
! %all information about their entities, as a list of objects of
! %type \var{Entity}. Similarly, entities collect objects defining
! %attributes and relationships. A \var{model} instance may also 
! %define bi-directional relationships as associations. The python
! %classes for each of these is described below. To reduce boilerplate
! %code, PyModels allow defaults to be specified for all values. 
! %Furthermore, sub-types for frequently used constructs are provided,
! %and others may of course be defined as necessary. 
! %
! %\subsection{A sample PyModel}
! %
! %Before dealing with all teh details, here is an overview of
! %a PyModel. Note the the \var{id} default property for entities,
! %as well as the predefined \var{Attribute} sub-types, 
! %\var{APrimaryKey} and \var{AString}.
! %
! %\begin{verbatim}
! %from Modeling.PyModel import *
! %
! %Entity.defaults['properties'] = [
! %  APrimaryKey('id', isClassProperty=0, isRequired=1, doc='Primary key!')
! %]
! %AString.defaults['width'] = 30
! %
! %model = Model('StoreEmployees',adaptorName='Postgresql',
! %		   connDict={'database': 'STORE_EMPLOYEES'} )
! %
! %model.entities = [
! %    Entity('Employee',
! %	 properties = [
! %	     AString('corporateName', isRequired=1),
! %	 ]
! %    ),
! %    Entity('SalesClerk', parent='Employee',
! %	 properties = [ ... ]
! %    ),
! %    Entity('Mark', 
! %	 properties = [ ... ] 
! %    )
! %    Entity('Store',
! %	 properties = [ ... ] 
! %    )
! %]
! %model.associations = [
! %    Association('Employee', 'Store'),
! %    Association('Mark', 'Employee'),
! %]
! %\end{verbatim}
! %
! %\subsection{PyModel types in detail}
! %
! %\subsubsection{Model}
! %
! %tbd.
! %
! %\subsubsection{Entity}
! %
! %tbd.
! %
! %\subsubsection{Attribute}
! %
! %    AInteger, AString, AFloat, ADateTime, APrimaryKey, AForeignKey
! %
! %\subsubsection{Relationship}
! %
! %    RToOne, RToMany
! %
! %\subsubsection{Association}
! %
! %tbd. 
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- 103,180 ----
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
! \section{PyModels}
! 
! A PyModel is a python module that defines a variable \var{model} 
! that is of type \var{Model}. Objects of type \var{Model} collect
! all information about their entities, as a list of objects of
! type \var{Entity}. Similarly, entities collect objects defining
! attributes and relationships. A \var{model} instance may also 
! define bi-directional relationships as associations. The python
! classes for each of these is described below. To reduce boilerplate
! code, PyModels allow defaults to be specified for all values. 
! Furthermore, sub-types for frequently used constructs are provided,
! and others may of course be defined as necessary. 
! 
! \subsection{A sample PyModel}
! 
! Before dealing with all the details, here is an overview of
! a PyModel. Note the the \var{id} default property for entities,
! as well as the predefined \var{Attribute} sub-types, 
! \var{APrimaryKey} and \var{AString}.
! 
! \begin{verbatim}
! from Modeling.PyModel import *
! 
! Entity.defaults['properties'] = [
!   APrimaryKey('id', isClassProperty=0, isRequired=1, doc='Primary key!')
! ]
! AString.defaults['width'] = 30
! 
! model = Model('StoreEmployees',adaptorName='Postgresql',
!               connDict={'database': 'STORE_EMPLOYEES'} )
! 
! model.entities = [
!     Entity('Employee',
!            properties = [
!              AString('corporateName', isRequired=1),
!            ]
!     ),
!     Entity('SalesClerk', parent='Employee',
!            properties = [ ... ]
!     ),
!     Entity('Mark', 
!            properties = [ ... ] 
!     )
!     Entity('Store',
!            properties = [ ... ] 
!     )
! ]
! model.associations = [
!     Association('Employee', 'Store'),
!     Association('Mark', 'Employee'),
! ]
! \end{verbatim}
! 
! \subsection{PyModel types in detail}
! 
! \subsubsection{Model}
! 
! tbd.
! 
! \subsubsection{Entity}
! 
! tbd.
! 
! \subsubsection{Attribute}
! 
!     AInteger, AString, AFloat, ADateTime, APrimaryKey, AForeignKey
! 
! \subsubsection{Relationship}
! 
!     RToOne, RToMany
! 
! \subsubsection{Association}
! 
! tbd. 
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
***************
*** 411,417 ****
          \code{string}, \code{'int'}\footnote{Note that python types \code{int}
          and \code{long int} are treated the same way. This is due to different
!         DB-adaptors having different behaviours --I also noticed that
!         \module{pgdb} can have a ''non-deterministic'' behaviour: sometimes it
!         returns \code{int}, sometimes \code{long int}, for the same db-field
          and the same value (e.g. 42); anyway it sounds reasonable to consider
          \code{int} and \code{long int} as equivalent within the framework's
--- 409,415 ----
          \code{string}, \code{'int'}\footnote{Note that python types \code{int}
          and \code{long int} are treated the same way. This is due to different
!         DB-adaptors having different behaviours --some can also
!         have a ''non-deterministic'' behaviour: sometimes 
!         returning \code{int}, sometimes \code{long int}, for the same db-field
          and the same value (e.g. 42); anyway it sounds reasonable to consider
          \code{int} and \code{long int} as equivalent within the framework's