[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gnue/forms INSTALL.win32 setup.py doc/techref.t...
|
From: |
James Thompson |
|
Subject: |
gnue/forms INSTALL.win32 setup.py doc/techref.t... |
|
Date: |
Mon, 01 Jul 2002 20:32:48 -0400 |
CVSROOT: /cvsroot/gnue
Module name: gnue
Changes by: James Thompson <address@hidden> 02/07/01 20:32:47
Modified files:
forms : INSTALL.win32 setup.py
forms/doc : techref.txt
forms/src : GFClient.py GFKeyMapper.py
Log message:
Removed references to PyXML
UI driver load failure now generates error instead of fail silent
Ctrl-UP/Ctrl-Down tied to First/Last record jump
updated docs(i guess, it's been a while :)
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/forms/INSTALL.win32.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/forms/setup.py.diff?tr1=1.70&tr2=1.71&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/forms/doc/techref.txt.diff?tr1=1.5&tr2=1.6&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/forms/src/GFClient.py.diff?tr1=1.45&tr2=1.46&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/forms/src/GFKeyMapper.py.diff?tr1=1.8&tr2=1.9&r1=text&r2=text
Patches:
Index: gnue/forms/INSTALL.win32
diff -c gnue/forms/INSTALL.win32:1.4 gnue/forms/INSTALL.win32:1.5
*** gnue/forms/INSTALL.win32:1.4 Mon Nov 5 22:55:24 2001
--- gnue/forms/INSTALL.win32 Mon Jul 1 20:32:47 2002
***************
*** 6,13 ****
Python 2.x+ www.python.org (1.X python will not work)
wxPython The GUI widget set
http://www.wxpython.org/download.php
- PyXML XML parser tools
- http://sourceforge.net/projects/pyxml
mxDateTime http://www.lemburg.com/files/python/mxDateTime.html
A supported DB driver (tested so far, others should work)
--- 6,11 ----
Index: gnue/forms/doc/techref.txt
diff -c gnue/forms/doc/techref.txt:1.5 gnue/forms/doc/techref.txt:1.6
*** gnue/forms/doc/techref.txt:1.5 Fri May 31 21:27:44 2002
--- gnue/forms/doc/techref.txt Mon Jul 1 20:32:47 2002
***************
*** 1,34 ****
-
-
GNU Entrprise - GNUe Forms
Technical Reference
! This is version 0.1.5 of the Technical Reference it covers
! GNUe Forms 0.1.0
! The current copy is maintained as a LyX 1.1.6 file. If anyone
! knows of ways to get LyX to play nicer with regard to code
! samples please let us know.
! This document is covered by the GNU Free Documentation License
! Version 1.1
- Introduction
- GNUE Forms aims to be the primary user interface to the GNU
- Enterprise system. It is comprised of two systems. GNUe
- Forms is responsible for displaying output and accepting
- user input. GNUe Designer allows a developer to produce
- the XML based form definition files utilized by GNUe Forms:
- Client.
! During development this document will serve as both a guide
! to the design of the GNUE Forms system and as a users guide.
Features
! To facilitate the development of data entry screens GNUE
! Forms supports the following features
+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Data-Aware Widgets | Ties user interface widgets directly to underling
data sources.
|
--- 1,35 ----
GNU Entrprise - GNUe Forms
Technical Reference
! This is version 0.1.5 of the Technical Reference it
! covers GNUe Forms 0.1.0
! The current copy is maintained as a LyX 1.1.6 file. If
! anyone knows of ways to get LyX to play nicer with
! regard to code samples please let us know.
! This document is covered by the GNU Free Documentation
! License Version 1.1
! Introduction
!
! GNUE Forms aims to be the primary user interface to the
! GNU Enterprise system. It is comprised of two systems.
! GNUe Forms is responsible for displaying output and
! accepting user input. GNUe Designer allows a developer
! to produce the XML based form definition files utilized
! by GNUe Forms: Client.
!
! During development this document will serve as both a
! guide to the design of the GNUE Forms system and as a
! users guide.
Features
! To facilitate the development of data entry screens
! GNUE Forms supports the following features
+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Data-Aware Widgets | Ties user interface widgets directly to underling
data sources.
|
***************
*** 43,90 ****
Design Overview
! GNUE Forms approaches the user interface differently than
! many applications. In GNUE Forms the user interface exists
! as two separate pieces. The first is a virtual form that
! exists in memory and reflects the structure and state of
! the user interface. The second is a slave hierarchy of widgets
! which are created by a UI driver to represent that specific
! driver's interpretation of the user interface describe by
! the first structure. An event mechanism allows the two separate
! pieces to communicate. The GNUE Forms tools will attempt
! to hide most of this separation of logic and UI from the
! application user and developer during typical usage.
Virtual Form
! All the actual logic of the form is carried out in the virtual
! form and reflected by the UI driver. The UI driver passes
! requests back to the virtual form when the user requests
! that something be changed.
UI System
! The widget hierarchy is the visible portion of an GNUE Forms
! application. Basically it's comprised of the various buttons,
! fields, menus, pictures, etc that are needed to build the
! user interface that manipulates the logical hierarchy to
! produce desired results. The user interface visible to the
! user isn't allowed to manipulate any data within the form
! and instead must pass requests back to the virtual form
! for processing.
Logical Focus
! One major difference in GNUE Forms applications vs typical
! widget based applications is in regard to focus. Focus in
! an GNUE Forms application typically occurs at the logical
! hierarchy level and is then reflected in the UI.
!
! Focus also follows the logical hierarchy of an application.
! Thus if focus currently resides in Block1.Field1 of an application
! and the user presses the Next Field key the focus of the
! application changes as follows assuming all triggers return
! successfully.
Block1.Field1 Pre-Focus-Out Trigger fires if defined
--- 44,94 ----
Design Overview
! GNUE Forms approaches the user interface differently
! than many applications. In GNUE Forms the user
! interface exists as two separate pieces. The first is a
! virtual form that exists in memory and reflects the
! structure and state of the user interface. The second
! is a slave hierarchy of widgets which are created by a
! UI driver to represent that specific driver's
! interpretation of the user interface describe by the
! first structure. An event mechanism allows the two
! separate pieces to communicate. The GNUE Forms tools
! will attempt to hide most of this separation of logic
! and UI from the application user and developer during
! typical usage.
Virtual Form
! All the actual logic of the form is carried out in the
! virtual form and reflected by the UI driver. The UI
! driver passes requests back to the virtual form when
! the user requests that something be changed.
UI System
! The widget hierarchy is the visible portion of an GNUE
! Forms application. Basically it's comprised of the
! various buttons, fields, menus, pictures, etc that are
! needed to build the user interface that manipulates the
! logical hierarchy to produce desired results. The user
! interface visible to the user isn't allowed to
! manipulate any data within the form and instead must
! pass requests back to the virtual form for processing.
Logical Focus
! One major difference in GNUE Forms applications vs
! typical widget based applications is in regard to
! focus. Focus in an GNUE Forms application typically
! occurs at the logical hierarchy level and is then
! reflected in the UI.
!
! Focus also follows the logical hierarchy of an
! application. Thus if focus currently resides in
! Block1.Field1 of an application and the user presses
! the Next Field key the focus of the application changes
! as follows assuming all triggers return successfully.
Block1.Field1 Pre-Focus-Out Trigger fires if defined
***************
*** 116,137 ****
Page
! The page object, when seen by a UI driver, suggests a visual
! separation of the UI is needed. However it is up the the
! UI driver to determine what, if any, type of visual separation
! is provided. Currently all UI drivers break these forms
! into actual pages. However nothing prevents the driver from
! using a notebook widget for separation or ignoring it altogether.
Block
! Blocks provide a way to logically group form objects in memory
! and provide navigation logic to the form. It is always linked
! to a datasource (described below) to provide persistence
! to the entry objects it contains. Blocks that are not associated
! with a datasource by the form definition file have a non-persistent
! datasource created for them automatically. If information
! within such blocks requires saving it is up to the application
developer to implement persistence via the Trigger system.
Label
--- 120,143 ----
Page
! The page object, when seen by a UI driver, suggests a
! visual separation of the UI is needed. However it is up
! the the UI driver to determine what, if any, type of
! visual separation is provided. Currently all UI drivers
! break these forms into actual pages. However nothing
! prevents the driver from using a notebook widget for
! separation or ignoring it altogether.
Block
! Blocks provide a way to logically group form objects in
! memory and provide navigation logic to the form. It is
! always linked to a datasource (described below) to
! provide persistence to the entry objects it contains.
! Blocks that are not associated with a datasource by the
! form definition file have a non-persistent datasource
! created for them automatically. If information within
! such blocks requires saving it is up to the application
developer to implement persistence via the Trigger system.
Label
***************
*** 140,337 ****
Entry
! Entry objects are the point at which information enters the
! system. They are mapped on a one-to-one basis with the fields
! contained within the datsource associated with the entry
! object's parent block. However it is possible to create
! entry object that does not map to any field in the datasource.
! When this happens a non persistant field is created in the
! datasource automatically. This is usefull for displaying
! information that is computed at run time. However this information
! will not be saved upon application exit.
Button
! The button object allows you to place interactive spots on
! your form that when activated will fire a named trigger.
Box
! The box object, when seen by a UI driver, suggests a border
! of some type is needed on the UI. However it is up the the
! UI driver to determine what, if any, type of border is provided.
Database
! Database objects provide the authenticated link to a specific
! data storage system. Various providers have been written
! to allow GNUE Forms to access different backends. A provider
! will provide the linkage to the GEAS system when it is completed.
! In fact it should be possible to write providers to access
! data from any external source of information as long as
! the provider presents its information in a record/field
! format.
Datasource
! A datasource contains records and fields of information currently
! loaded into an active form. Typically it is linked to a
! defined database and associates itself with a specific source,
! like a table, in that database. However it is possible to
! have datasources that have no database link defined. These
! types of datasources cannot provide persistance to the information
! stored within themself.
Master/Detail Relationships
! Datasources can also be associated with other datasoure in
! what we call a Master/Detail relationship. A master datasource
! has one or more detail datasources associated with itself.
! These detail datasources contain a foreign key which points
! back to a specific master datasource/field key. When navigation
! to a different record in the master datasource takes place
! all detail datasources auto navigate to the matching records
! within themselves to maintain integrity of the data being
! displayed. It's worth noting that a datasource can be both
! a detail and master datasource simultaneously.
Record Caching/Prefetch
! In an effort to improve system performance datasources will
! eventually be able to be configured to cache records in
! memory. The application developer will have control over
! the number of records cached to allow them to balance memory
! usage vs system responsiveness. Currently the cache system
! in GNUe is, in reality, a pre-fetch system. When large numbers
! of records are requested from the database the system will
! fetch only the user-specified "cache
! amount" at a time. When the user moves beyond the
! number of records in memory, the system will automatically
! fetch another group of records. This allows the system to
! respond rapidly to user requests involving large number
! of records.
Triggers
! Triggers contain scripts of code that execute during specific
! events which "fire" the triggers. They can be attached to
! any of the components of the virtual form though some trigger
! events may not pertain to the component and, as such, will
! never fire.
!
! Not implemented yet: Triggers normally return a True value
! upon sucessful completion. It is possible for the trigger
! script to return True or False values to influence the applications
! behaviour.
Trigger Languages
! Currently, trigger scripts must be written in python. We
! would like to increase the number of supported languages
! as time permits.
Trigger Events
! The following triggers are either implemented or planned
! for implementation in the GNUe Forms system. Unless specifically
! mentioned the return value of the script will not effect
! the application in any way.
! Note: The ability to return true false values is not yet
! implemented in GNUE Forms.
Implemented
! Entry
! Pre-FocusOut - Fires prior to a component losing focus.
! If the return value of the script is False then the focus
! will not be switched.
! Post-FocusOut - Fires after focus leaves a component but
! prior to new component taking focus.
! Pre-FocusIn - Fires prior to a component recieving focus.
Post-FocusIn - Fires after a component recieves focus.
! Block
! Pre-FocusOut - Fires prior to a component losing focus.
! If the return value of the script is False then the focus
! will not be switched.
! Post-FocusOut - Fires after focus leaves a component but
! prior to new component taking focus.
! Pre-FocusIn - Fires prior to a component recieving focus.
Post-FocusIn - Fires after a component recieves focus.
! Pre-Commit - Fires once, for each record in the block marked
! as either "new", "updated",
! or "deleted", prior to commiting the
! record into persistant storage. In the future, if the
! return value of the script is False then the commit will
! be aborted.
!
! Pre-Insert - Fires once, for each record in the block marked
! as "new", and commiting the record into
! persistant storage. In the future, if the return value
! of the script is False then the commit will be aborted.
! This event is called prior to the pre-commit event.
!
! Pre-Update - Fires once, for each record in the block marked
! as "updated", prior to updating and
! commiting the record into persistant storage. In the future,
! if the return value of the script is False then the commit
! will be aborted. This event is called prior to the pre-commit
! event.
!
! Pre-Delete - Fires once, for each record in the block marked
! as "deleted", prior to deleting and
! commiting the record into persistant storage. In the future,
! if the return value of the script is False then the commit
! will be aborted. This event is called prior to the pre-commit
! event.
Post-Commit - Fires after data has been commited.
! Page
! Pre-FocusOut - Fires prior to a component losing focus.
! If the return value of the script is False then the focus
! will not be switched.
! Post-FocusOut - Fires after focus leaves a component but
! prior to new component taking focus.
! Pre-FocusIn - Fires prior to a component recieving focus.
Post-FocusIn - Fires after a component recieves focus.
! Form
! Pre-Commit- Fires prior to commiting data into persistant
! storage. If the return value of the script is False then
! the commit will be aborted.
Post-Commit - Fires after data has been commited.
Not Implemented
! Pre-Change - Fires prior to a change to an component.
! If the return value of the script is False then the change
! will be aborted.
! Post-Change Fires after a change to an component.
! On-newrecord Fires whenever a new record is created.
Example of Logical Hierarchy
! A visual representation of how these items fit together is
! in order.
Here is a simple data entry form:
--- 146,350 ----
Entry
! Entry objects are the point at which information enters
! the system. They are mapped on a one-to-one basis with
! the fields contained within the datsource associated
! with the entry object's parent block. However it is
! possible to create entry object that does not map to
! any field in the datasource. When this happens a non
! persistant field is created in the datasource
! automatically. This is usefull for displaying
! information that is computed at run time. However this
! information will not be saved upon application exit.
Button
! The button object allows you to place interactive spots
! on your form that when activated will fire a named trigger.
Box
! The box object, when seen by a UI driver, suggests a
! border of some type is needed on the UI. However it is
! up the the UI driver to determine what, if any, type of
! border is provided.
Database
! Database objects provide the authenticated link to a
! specific data storage system. Various providers have
! been written to allow GNUE Forms to access different
! backends. A provider will provide the linkage to the
! GEAS system when it is completed. In fact it should be
! possible to write providers to access data from any
! external source of information as long as the provider
! presents its information in a record/field format.
Datasource
! A datasource contains records and fields of information
! currently loaded into an active form. Typically it is
! linked to a defined database and associates itself with
! a specific source, like a table, in that database.
! However it is possible to have datasources that have no
! database link defined. These types of datasources
! cannot provide persistance to the information stored
! within themself.
Master/Detail Relationships
! Datasources can also be associated with other datasoure
! in what we call a Master/Detail relationship. A master
! datasource has one or more detail datasources
! associated with itself. These detail datasources
! contain a foreign key which points back to a specific
! master datasource/field key. When navigation to a
! different record in the master datasource takes place
! all detail datasources auto navigate to the matching
! records within themselves to maintain integrity of the
! data being displayed. It's worth noting that a
! datasource can be both a detail and master datasource
! simultaneously.
Record Caching/Prefetch
! In an effort to improve system performance datasources
! will eventually be able to be configured to cache
! records in memory. The application developer will have
! control over the number of records cached to allow them
! to balance memory usage vs system responsiveness.
! Currently the cache system in GNUe is, in reality, a
! pre-fetch system. When large numbers of records are
! requested from the database the system will fetch only
! the user-specified "cache amount" at a time. When the
! user moves beyond the number of records in memory, the
! system will automatically fetch another group of
! records. This allows the system to respond rapidly to
! user requests involving large number of records.
Triggers
! Triggers contain scripts of code that execute during
! specific events which "fire" the triggers. They can be
! attached to any of the components of the virtual form
! though some trigger events may not pertain to the
! component and, as such, will never fire.
!
! Not implemented yet: Triggers normally return a True
! value upon sucessful completion. It is possible for the
! trigger script to return True or False values to
! influence the applications behaviour.
Trigger Languages
! Currently, trigger scripts must be written in python.
! We would like to increase the number of supported
! languages as time permits.
Trigger Events
! The following triggers are either implemented or
! planned for implementation in the GNUe Forms system.
! Unless specifically mentioned the return value of the
! script will not effect the application in any way.
! Note: The ability to return true false values is not
! yet implemented in GNUE Forms.
Implemented
! Entry
! Pre-FocusOut - Fires prior to a component losing
! focus. If the return value of the script is False
! then the focus will not be switched.
! Post-FocusOut - Fires after focus leaves a component
! but prior to new component taking focus.
! Pre-FocusIn - Fires prior to a component recieving
! focus.
Post-FocusIn - Fires after a component recieves focus.
! Block
! Pre-FocusOut - Fires prior to a component losing
! focus. If the return value of the script is False
! then the focus will not be switched.
! Post-FocusOut - Fires after focus leaves a component
! but prior to new component taking focus.
! Pre-FocusIn - Fires prior to a component recieving
! focus.
Post-FocusIn - Fires after a component recieves focus.
! Pre-Commit - Fires once, for each record in the block
! marked as either "new", "updated", or "deleted", prior to
! commiting the record into persistant storage. In the
! future, if the return value of the script is False
! then the commit will be aborted.
!
! Pre-Insert - Fires once, for each record in the block
! marked as "new", and commiting the record into
! persistant storage. In the future, if the return
! value of the script is False then the commit will be
! aborted. This event is called prior to the pre-commit event.
!
! Pre-Update - Fires once, for each record in the block
! marked as "updated", prior to updating and commiting
! the record into persistant storage. In the future, if
! the return value of the script is False then the
! commit will be aborted. This event is called prior to
! the pre-commit event.
!
! Pre-Delete - Fires once, for each record in the block
! marked as "deleted", prior to deleting and commiting
! the record into persistant storage. In the future, if
! the return value of the script is False then the
! commit will be aborted. This event is called prior to
! the pre-commit event.
Post-Commit - Fires after data has been commited.
! Page
! Pre-FocusOut - Fires prior to a component losing
! focus. If the return value of the script is False
! then the focus will not be switched.
! Post-FocusOut - Fires after focus leaves a component
! but prior to new component taking focus.
! Pre-FocusIn - Fires prior to a component recieving
! focus.
Post-FocusIn - Fires after a component recieves focus.
! Form
! Pre-Commit- Fires prior to commiting data into
! persistant storage. If the return value of the script
! is False then the commit will be aborted.
Post-Commit - Fires after data has been commited.
Not Implemented
! Pre-Change - Fires prior to a change to an component.
! If the return value of the script is False then the
! change will be aborted.
! Post-Change Fires after a change to an component.
! On-newrecord Fires whenever a new record is created.
Example of Logical Hierarchy
! A visual representation of how these items fit together
! is in order.
Here is a simple data entry form:
***************
*** 381,445 ****
UI System
! The user interface in GNUe Forms is generated from the defined
! virutal form. Thus the form designer doesn't need to concern
! themself with the features of a specific widget set. Instead
! the form designer describes the form's function and a UI
! driver chooses the appropriate method of displaying that
! form based on the client's capabilities. However, this doesn't
! mean that the form designer has no control over how their
form looks.
Widget Coordinates
! The coordinate/layout system for widget in GNUE Forms needs
! to be able to deal with text based displays as well as GUI
! systems. Thus sizes and coordinates for widgets will need
! to be specified in character coordinates. Exceptions to
! this will include widgets that display pictures. Support
! for grid style coordinates will be first then we will look
! at layout managers that provide relative positioning similar
! to X/Java as well as character coordinates like curses.
GNUE Forms: Client
Basic Concepts
! GNUE Forms clients read form definitions from XML based .gfd
! files. The client reads in a form definition file which
! describes the virutal form. The client then generates a
! data entry form based upon this information, initializes
! the user interface, then begins to accept user input. It
! is up to the client to determine the best method of mapping
! user interface widgets within it's technological limitations.
! Thus each client may make compromises based upon what it
! is and is not capable of performing. For instance, a client
! written to display forms via a web browser using plain HTML
! would be incapable doing input validation at run time. It
! could however elect to perform the validation prior to submitting
! the data back to persistant storage. Since some user interfaces
! require certain features to be present to be useful the
! form definition language allows the developer to tag required
! features. A client that is incapable of supporting the features
! can gracefully abort the session.
!
! Any application that can read and execute a .gfd file is
! in effect a GNUE Forms client. It should be possible to
! write clients for a varity of platforms and input/output
! devices.If a client meets the interface requirements set
! forth in this document and can provide the necessary basic
! features then all GNU Enterprise programs and screens should
! run without modification.
!
! The remainder of this chapter covers the reference implementation
! of the GNUe Forms client which has been written in python.
UI Drivers
! UI drivers are responsible for interacting with the user
! and passing user input back as requests to the virtual form.
! The following user interface drivers are available in the
! reference client.
+----------+---------------------------------------------------------------------------------------------+
| UI Type | Descrption
|
--- 394,463 ----
UI System
! The user interface in GNUe Forms is generated from the
! defined virutal form. Thus the form designer doesn't
! need to concern themself with the features of a
! specific widget set. Instead the form designer
! describes the form's function and a UI driver chooses
! the appropriate method of displaying that form based on
! the client's capabilities. However, this doesn't mean
! that the form designer has no control over how their
form looks.
Widget Coordinates
! The coordinate/layout system for widget in GNUE Forms
! needs to be able to deal with text based displays as
! well as GUI systems. Thus sizes and coordinates for
! widgets will need to be specified in character
! coordinates. Exceptions to this will include widgets
! that display pictures. Support for grid style
! coordinates will be first then we will look at layout
! managers that provide relative positioning similar to
! X/Java as well as character coordinates like curses.
GNUE Forms: Client
Basic Concepts
! GNUE Forms clients read form definitions from XML based
! .gfd files. The client reads in a form definition file
! which describes the virutal form. The client then
! generates a data entry form based upon this
! information, initializes the user interface, then
! begins to accept user input. It is up to the client to
! determine the best method of mapping user interface
! widgets within it's technological limitations. Thus
! each client may make compromises based upon what it is
! and is not capable of performing. For instance, a
! client written to display forms via a web browser using
! plain HTML would be incapable doing input validation at
! run time. It could however elect to perform the
! validation prior to submitting the data back to
! persistant storage. Since some user interfaces require
! certain features to be present to be useful the form
! definition language allows the developer to tag
! required features. A client that is incapable of
! supporting the features can gracefully abort the session.
!
! Any application that can read and execute a .gfd file
! is in effect a GNUE Forms client. It should be possible
! to write clients for a varity of platforms and
! input/output devices.If a client meets the interface
! requirements set forth in this document and can provide
! the necessary basic features then all GNU Enterprise
! programs and screens should run without modification.
!
! The remainder of this chapter covers the reference
! implementation of the GNUe Forms client which has been
! written in python.
UI Drivers
! UI drivers are responsible for interacting with the
! user and passing user input back as requests to the
! virtual form. The following user interface drivers are
! available in the reference client.
+----------+---------------------------------------------------------------------------------------------+
| UI Type | Descrption
|
***************
*** 460,467 ****
Running the client is rather simple. In it's most basic form
gfclient formname.gfd
! The formname.gfd can be in the form of a normal file or a
! URL such as a web address
To get a list of available options
--- 478,485 ----
Running the client is rather simple. In it's most basic form
gfclient formname.gfd
! The formname.gfd can be in the form of a normal file or
! a URL such as a web address
To get a list of available options
***************
*** 470,483 ****
Symlinks
! gfclient also supports the use of symlinks to simplify execution
! of forms. The easiest way to describe this is by example.
!
! If you have a form called contacts.gfd in the default location
! (specified in GFOptions.py). Then by placing into your path
! a symbolic link called contacts which points to the gfclient
! executable you will be able to execute the file by simply
! typing contacts.
bash-2.03$ ln -s /usr/local/bin/gfclient /usr/local/bin/contacts
bash-2.03$ contacts
--- 488,502 ----
Symlinks
! gfclient also supports the use of symlinks to simplify
! execution of forms. The easiest way to describe this is
! by example.
!
! If you have a form called contacts.gfd in the default
! location (specified in GFOptions.py). Then by placing
! into your path a symbolic link called contacts which
! points to the gfclient executable you will be able to
! execute the file by simply typing contacts.
bash-2.03$ ln -s /usr/local/bin/gfclient /usr/local/bin/contacts
bash-2.03$ contacts
***************
*** 485,492 ****
GFD Structure
! Forms are described via a .gfd file. A GFD file always contains
! the following structure
XML version
--- 504,511 ----
GFD Structure
! Forms are described via a .gfd file. A GFD file always
! contains the following structure
XML version
***************
*** 532,539 ****
Example
! <form title="My Form" width="40"
! height="40">
Rest of form logic goes here
--- 551,557 ----
Example
! <form title="My Form" width="40" height="40">
Rest of form logic goes here
***************
*** 590,609 ****
Example
! <block name="cities" datasource="city" master="state.st_code"
! detail="state">
label and entry objects that are part of this block go here
</block>
! The cities block defined in the above example is a detail
! block. It is linked to a datasource named city and it keeps
! the data displayed within itself in sync with the block
! named state. It does this by monitoring the entry named
! st_code in the state block, when that data changes it sets
! the entry within itself named state to match the value stored
! in st_code as querying data from the datasource.
<label>
--- 608,628 ----
Example
! <block name="cities" datasource="city"
! master="state.st_code" detail="state">
label and entry objects that are part of this block go here
</block>
! The cities block defined in the above example is a
! detail block. It is linked to a datasource named city
! and it keeps the data displayed within itself in sync
! with the block named state. It does this by monitoring
! the entry named st_code in the state block, when that
! data changes it sets the entry within itself named
! state to match the value stored in st_code as querying
! data from the datasource.
<label>
***************
*** 613,619 ****
| Attribute | Datatype | Default | Description
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------+
+------------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------+
! | x | int | none | The text column starting position of
the widget . Based upon leftmost column of screen being 0.
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------+
| y | int | none | The text row starting position of the
widget. Based upon the top row of the screen being 0.
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------+
--- 632,638 ----
| Attribute | Datatype | Default | Description
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------+
+------------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------+
! | x | int | none | The text column starting position of
the widget . Based upon leftmost column of screen being 0.
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------+
| y | int | none | The text row starting position of the
widget. Based upon the top row of the screen being 0.
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------+
***************
*** 675,681 ****
+--------------------------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| foreign_key_descritpion | string | none | The
description used if a style of dropdown is selected. This fields value is
displayed in the dropdown but the foreign_key value is actually stored in the
field. This allows you to display something like the full name of a US state
but only store it's 2 character abrievation. |
+--------------------------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
! | style | string | text | The style
of entry widget requested. Currently either text, label, checkbox, or dropdown.
To use dropdown you are required to use both the foreign_key and
foreign_key_descriptions attributes. The "label" style implies the readonly
attribute. |
+--------------------------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| default | string | none | The
default value for any new records created. If the field is visible the user can
override the value.
|
+--------------------------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
--- 694,700 ----
+--------------------------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| foreign_key_descritpion | string | none | The
description used if a style of dropdown is selected. This fields value is
displayed in the dropdown but the foreign_key value is actually stored in the
field. This allows you to display something like the full name of a US state
but only store it's 2 character abrievation. |
+--------------------------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
! | style | string | text | The style
of entry widget requested. Currently either text, label, checkbox, or dropdown.
To use dropdown you are required to use both the foreign_key and
foreign_key_descriptions attributes. The ""label style implies the readonly
attribute. |
+--------------------------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| default | string | none | The
default value for any new records created. If the field is visible the user can
override the value.
|
+--------------------------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
***************
*** 701,711 ****
A more complex example
! <entry name="state" field="state_code" x="17" y="2" width="15"
! visibleCount="15" uppercase=""
! foreign_key="validator.state" foreign_key_description="description"
! style="dropdown">
<button>
--- 720,730 ----
A more complex example
! <entry name="state" field="state_code" x="17" y="2"
! width="15" visibleCount="15" uppercase=""
! foreign_key="validator.state"
! foreign_key_description="description" style="dropdown">
<button>
***************
*** 733,740 ****
Example
! <button label="Press Me" x="1" y="1" width="10" height="1"
! trigger="HelloWorld"/>
<box>
--- 752,759 ----
Example
! <button label="Press Me" x="1" y="1" width="10"
! height="1" trigger="HelloWorld"/>
<box>
***************
*** 744,750 ****
| Attribute | Datatype | Default | Description
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
! | x | int | none | The text column starting position of
the widget . Based upon leftmost column of screen being 0. |
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
| y | int | none | The text row starting position of the
widget. Based upon the top row of the screen being 0. |
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
--- 763,769 ----
| Attribute | Datatype | Default | Description
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
! | x | int | none | The text column starting position of
the widget . Based upon leftmost column of screen being 0. |
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
| y | int | none | The text row starting position of the
widget. Based upon the top row of the screen being 0. |
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
***************
*** 762,769 ****
<scrollbar>
! Only partially implemented at this time. Will show on form
! but do nothing.
Attributes
--- 781,788 ----
<scrollbar>
! Only partially implemented at this time. Will show on
! form but do nothing.
Attributes
***************
*** 771,777 ****
| Attribute | Datatype | Default | Description
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
! | x | int | none | The text column starting position of
the widget . Based upon leftmost column of screen being 0. |
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
| y | int | none | The text row starting position of the
widget. Based upon the top row of the screen being 0. |
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
--- 790,796 ----
| Attribute | Datatype | Default | Description
|
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
! | x | int | none | The text column starting position of
the widget . Based upon leftmost column of screen being 0. |
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
| y | int | none | The text row starting position of the
widget. Based upon the top row of the screen being 0. |
+------------+-----------+----------+--------------------------------------------------------------------------------------------------+
***************
*** 809,816 ****
Example
! <datasource name="customers" database="gnue" table="customer"
! order_by="name_last,name_first" prequery="" />
<trigger>
--- 828,836 ----
Example
! <datasource name="customers" database="gnue"
! table="customer" order_by="name_last,name_first"
! prequery="" />
<trigger>
***************
*** 858,863 ****
--- 878,927 ----
# import sys
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
blckPOItem.fields.ntryAmount=str(int(blckPOItem.fields.ntryQuantity)*float(blckPOItem.fields.ntryUnitPrice))
</trigger>
***************
*** 878,908 ****
Overview
! Forms supports libraries of common objects. There are two
! approaches to importing data in forms: 1) importing form-wide
! objects such as named triggers, pages, and datasources;
! and 2) importing individual objects, such as blocks, entries,
! triggers, pages, and datasources. Note that the first method
! works only for form-level objects, whereas the second method
! works for any "namable"
! form object (including namable form-level objects).
!
! There is no markup difference between a form library and
! a form definition. Forms can pull objects from other forms
! just as easily as from a library. For convenience, form
! definitions that are only used as libraries use the .gfl
! extension.
!
! All child objects of an imported item are imported as well.
! For example, when importing a page, all blocks, labels,
! etc. belowing to that page are imported as well.
Importing Form-Level Objects
Summary
! The first method of importing uses the <import> tag. The
! import tag takes four attributes:
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
| Attribute | Datatype | Default | Description
|
--- 942,972 ----
Overview
! Forms supports libraries of common objects. There are
! two approaches to importing data in forms: 1) importing
! form-wide objects such as named triggers, pages, and
! datasources; and 2) importing individual objects, such
! as blocks, entries, triggers, pages, and datasources.
! Note that the first method works only for form-level
! objects, whereas the second method works for any "namable"
! form object (including namable form-level objects).
!
! There is no markup difference between a form library
! and a form definition. Forms can pull objects from
! other forms just as easily as from a library. For
! convenience, form definitions that are only used as
! libraries use the .gfl extension.
!
! All child objects of an imported item are imported as
! well. For example, when importing a page, all blocks,
! labels, etc. belowing to that page are imported as well.
Importing Form-Level Objects
Summary
! The first method of importing uses the <import> tag.
! The import tag takes four attributes:
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
| Attribute | Datatype | Default | Description
|
***************
*** 910,968 ****
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
| library | string | none | The URL or file name of the form or
library to pull the imported data from.
|
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
! | datasources | string | none | Specifies a comma separated list of
datasources by name to import. If set to "*", then loads all datasources from
the library. |
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
! | triggers | string | none | Specifies a comma separated list of
named triggers by id to import. If set to "*", then loads all named triggers
from the library. |
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
! | pages | string | none | Specifies a comma separated list of
names of pages to import. If set to "*", then loads all pages INCLUDING unnamed
pages from the library. |
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
Example
Import all datasources and the pages identified as "page1"
! and "page2":
! <import library="mylibrary.gfl"
! datasources="*" pages="page1,page2"/>
Importing Individual Objects
Summary
! The second method of importing involves importing named objects.
! The currently importable objects are: datasource, page,
! block, trigger, button, and entry.
!
! The tag for importing these objects is the <import-[object]>
! tag, where [object] is the type of object being imported.
! For example, the tag for importing blocks is <import-block>.
!
! All <import-[object]> style tags take a minimum of two tags,
! location and name, plus any tags available to the imported
! tag. Location works the same as in the above table for form-level
! objects.
!
! Any of these extra tags override the values of the imported
! tag. For example, the datasource tag supports the database
! tag. Therefore, the import-datasource tag also supports
! the database tag. If database is specified on the import-datasource
! tag, then this value overrides the value set in the library
! file. This is especially useful for master-detail datasources
! as a common detail block can be defined in a library, but
the master datasource may be different in each form.
Example
Import a datasource:
! <import-datasource location="mylibrary.gfl"
! name="dszipcodes"/>
Import an entry, overriding the bounded field:
! <import-entry location="mylibrary.gfl"
! name="zipentry" field="zipfield2"/>
Complete Example
--- 974,1032 ----
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
| library | string | none | The URL or file name of the form or
library to pull the imported data from.
|
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
! | datasources | string | none | Specifies a comma separated list of
datasources by name to import. If set to ""*, then loads all datasources from
the library. |
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
! | triggers | string | none | Specifies a comma separated list of
named triggers by id to import. If set to ""*, then loads all named triggers
from the library. |
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
! | pages | string | none | Specifies a comma separated list of
names of pages to import. If set to ""*, then loads all pages INCLUDING unnamed
pages from the library. |
+--------------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------------------+
Example
Import all datasources and the pages identified as "page1"
! and "page2":
! <import library="mylibrary.gfl" datasources="*" pages="page1,page2"/>
Importing Individual Objects
Summary
! The second method of importing involves importing named
! objects. The currently importable objects are:
! datasource, page, block, trigger, button, and entry.
!
! The tag for importing these objects is the
! <import-[object]> tag, where [object] is the type of
! object being imported. For example, the tag for
! importing blocks is <import-block>.
!
! All <import-[object]> style tags take a minimum of two
! tags, location and name, plus any tags available to the
! imported tag. Location works the same as in the above
! table for form-level objects.
!
! Any of these extra tags override the values of the
! imported tag. For example, the datasource tag supports
! the database tag. Therefore, the import-datasource tag
! also supports the database tag. If database is
! specified on the import-datasource tag, then this value
! overrides the value set in the library file. This is
! especially useful for master-detail datasources as a
! common detail block can be defined in a library, but
the master datasource may be different in each form.
Example
Import a datasource:
! <import-datasource location="mylibrary.gfl" name="dszipcodes"/>
Import an entry, overriding the bounded field:
! <import-entry location="mylibrary.gfl" name="zipentry" field="
! zipfield2"/>
Complete Example
***************
*** 983,990 ****
</options>
! <datasource name="country" database="gnue" table="country"
! order_by="country"/>
<page>
--- 1047,1054 ----
</options>
! <datasource name="country" database="gnue"
! table="country" order_by="country"/>
<page>
***************
*** 992,1004 ****
<label text="Country" x="1" y="1"/>
! <entry name="country" field="country"
! x="1" y="2" width="50" visibleCount="10" uppercase="" max_length="50">
<options>
! <tip>The
! name of the country</tip>
</options>
--- 1056,1068 ----
<label text="Country" x="1" y="1"/>
! <entry name="country" field="country" x="1" y="2"
! width="50" visibleCount="10" uppercase=""
! max_length="50">
<options>
! <tip>The name of the country</tip>
</options>
***************
*** 1012,1070 ****
Dealing with Technological Limitations
! The design goals of GNUE Forms places some unique constraints
! upon the client applications. A form developer does not
! necessarily know the type technology that will be used to
! interact with his form.
!
! It is quite possible that a form originally designed to run
! on a blazing fast workstation with a 21" color monitor could
! end up being utilized on a text only amber terminal.
!
! While GNUE Form client developers are encouraged to support
! as many widgets as is possible on their target technology.
! We understand that some technology cannot physically accommodate
! every widget supported by GNUE Forms.
We deal with this in following ways
Best Judgment
! Client developers are given a lot of flexibility in implementing
! GNUE Forms clients. A client developer can decide that implementing
! a specific feature in a limited fashion is better than not
! implementing it at all.
!
! An example of this would be in dealing with run time validation
! of input on the client side.
!
! While the GTK based client developers would have no issues
! with implementing this feature, it would be impossible for
! an HTML-only browser based client written in PHP. The HTML
! client developers could realisticly claim that users of
! the browser are aware of the limitations of HTML form inputs.
! These users are willing to accept the loss of real time
! validation for the convenience of using a browser as their
! input device. The developers could design the client to
! perform the input validation upon submission of the form
! containing user data.
!
! Widgets that would be impossible to implement could simply
! be ignored. Thus if a form displayed a picture of an employee
! on his personal information screen, a text based client
! could simply choose to ignore the picture.
Form Requirements
! Sometimes the omission of the data in the form might render
! a form useless. The loss of the ability to display the employee's
! picture in the above example might not be critical. However,
! a form whose sole purpose is to display scanned images would
! be worthless on a text only client.
!
! Form designer have the ability to tag certain features as
! critical to the forms ability to operate. When a client
! is unable to provide a feature it must
Notify the user of the missing feature
--- 1076,1137 ----
Dealing with Technological Limitations
! The design goals of GNUE Forms places some unique
! constraints upon the client applications. A form
! developer does not necessarily know the type technology
! that will be used to interact with his form.
!
! It is quite possible that a form originally designed to
! run on a blazing fast workstation with a 21" color
! monitor could end up being utilized on a text only
! amber terminal.
!
! While GNUE Form client developers are encouraged to
! support as many widgets as is possible on their target
! technology. We understand that some technology cannot
! physically accommodate every widget supported by GNUE Forms.
We deal with this in following ways
Best Judgment
! Client developers are given a lot of flexibility in
! implementing GNUE Forms clients. A client developer can
! decide that implementing a specific feature in a
! limited fashion is better than not implementing it at all.
!
! An example of this would be in dealing with run time
! validation of input on the client side.
!
! While the GTK based client developers would have no
! issues with implementing this feature, it would be
! impossible for an HTML-only browser based client
! written in PHP. The HTML client developers could
! realisticly claim that users of the browser are aware
! of the limitations of HTML form inputs. These users are
! willing to accept the loss of real time validation for
! the convenience of using a browser as their input
! device. The developers could design the client to
! perform the input validation upon submission of the
! form containing user data.
!
! Widgets that would be impossible to implement could
! simply be ignored. Thus if a form displayed a picture
! of an employee on his personal information screen, a
! text based client could simply choose to ignore the picture.
Form Requirements
! Sometimes the omission of the data in the form might
! render a form useless. The loss of the ability to
! display the employee's picture in the above example
! might not be critical. However, a form whose sole
! purpose is to display scanned images would be worthless
! on a text only client.
!
! Form designer have the ability to tag certain features
! as critical to the forms ability to operate. When a
! client is unable to provide a feature it must
Notify the user of the missing feature
Index: gnue/forms/setup.py
diff -c gnue/forms/setup.py:1.70 gnue/forms/setup.py:1.71
*** gnue/forms/setup.py:1.70 Mon Jun 3 15:19:39 2002
--- gnue/forms/setup.py Mon Jul 1 20:32:47 2002
***************
*** 29,43 ****
from src import VERSION
#
- # Leftover from initial attempt to create a .exe setup file for windows
- #
- try:
- import py2exe
- except:
- pass
-
-
- #
# hack to deal w/ fact distutils won't
# allow us to set absolute path prefix
# on windows
--- 29,34 ----
***************
*** 56,62 ****
try:
from distutils.core import setup
from distutils.command.build_scripts import build_scripts
- # from setupext import Data_Files, install_Data_Files
except ImportError:
print """
Setup requires that python's distutils be
--- 47,52 ----
***************
*** 94,118 ****
if ('build' in sys.argv) or ('install' in sys.argv):
- # Verify that gnue-common is installed
- # try:
- # print "Checking for GNUe-Common....",
- # from gnue import common
- # if common.__dict__.has_key('VERSION'):
- # print "OK (version %s)" % common.VERSION
- # else:
- # print "OK"
- # except ImportError:
- # print """
- #You will need to install gnue-common
- #before gnuef will function. You can
- #obtain a copy from
- #
- #http://www.gnuenterprise.org/download.php
- #"""
- # sys.exit()
-
-
#
# Verify at least one UI is installed
#
--- 84,89 ----
Index: gnue/forms/src/GFClient.py
diff -c gnue/forms/src/GFClient.py:1.45 gnue/forms/src/GFClient.py:1.46
*** gnue/forms/src/GFClient.py:1.45 Tue Jun 4 19:20:47 2002
--- gnue/forms/src/GFClient.py Mon Jul 1 20:32:47 2002
***************
*** 112,122 ****
self._ui = dyn_import("gnue.forms.uidrivers.%s" % (self.ui_type))
uiloaded = 1
except ImportError, err:
! GDebug.printMesg(0,'Unable to load UI driver %s' % (self.ui_type))
GDebug.printMesg(1,err)
if self.ui_type != 'nstti':
self.ui_type = 'nstti'
else:
sys.exit()
self.loadKeyMappings()
--- 112,123 ----
self._ui = dyn_import("gnue.forms.uidrivers.%s" % (self.ui_type))
uiloaded = 1
except ImportError, err:
! GDebug.printMesg(1,_("Unable to load UI driver")+" %s" % self.ui_type)
GDebug.printMesg(1,err)
if self.ui_type != 'nstti':
self.ui_type = 'nstti'
else:
+ self.handleStartupError(_("Unable to load any valid UI drivers.
Aborting."))
sys.exit()
self.loadKeyMappings()
Index: gnue/forms/src/GFKeyMapper.py
diff -c gnue/forms/src/GFKeyMapper.py:1.8 gnue/forms/src/GFKeyMapper.py:1.9
*** gnue/forms/src/GFKeyMapper.py:1.8 Tue May 7 13:24:13 2002
--- gnue/forms/src/GFKeyMapper.py Mon Jul 1 20:32:47 2002
***************
*** 278,283 ****
--- 278,285 ----
(vk.DELETE, 0, 0, 0) : 'DELETE',
(vk.UP, 0, 0, 0) : 'PREVRECORD',
(vk.DOWN, 0, 0, 0) : 'NEXTRECORD',
+ (vk.UP, 0, 1, 0) : 'FIRSTRECORD',
+ (vk.DOWN, 0, 1, 0) : 'LASTRECORD',
(vk.F2, 0, 0, 0) : 'JUMPRECORD',
(vk.F5, 0, 0, 0) : 'MARKFORDELETE',
(vk.F6, 0, 0, 0) : 'COMMIT',
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- gnue/forms INSTALL.win32 setup.py doc/techref.t...,
James Thompson <=