gnue/gnue-common/doc TriggerSpecifications.txt

[Jason Cater]

CVSROOT:        /home/cvs
Module name:    gnue
Changes by:     Jason Cater <address@hidden>    01/09/09 16:22:29

Modified files:
        gnue-common/doc: TriggerSpecifications.txt 

Log message:
        ** Fixed bugs w/isFieldBound (GDataObjects.py / dbdrivers/*/DBdriver.py)
        ** Moved GClientApp functionality to new GBaseApp
        ** Added GClientApp and GServerApp as extensions to GBaseApp
        In future, this will provide abstraction layers for:
        +  RPC calls (corba, XML-RPC, soap, unix sockets??)
        + Threading/AIO of server methods
        +  Spawning/daemon modes
        ** Completed migration from 'empty' dbdriver to '_empty'
        (Now, any _* dbdrivers are virtual -- i.e., not intended
        for use in connections.conf)
        ** Added comments to TriggerSpecifications.txt
        ** Removed old (unused) pg dbdriver directory

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue-common/doc/TriggerSpecifications.txt.diff?cvsroot=OldCVS&tr1=1.2&tr2=1.3&r1=text&r2=text

Patches:
Index: gnue/gnue-common/doc/TriggerSpecifications.txt
diff -u gnue/gnue-common/doc/TriggerSpecifications.txt:1.2 
gnue/gnue-common/doc/TriggerSpecifications.txt:1.3
--- gnue/gnue-common/doc/TriggerSpecifications.txt:1.2  Mon Sep  3 10:29:14 2001
+++ gnue/gnue-common/doc/TriggerSpecifications.txt      Sun Sep  9 16:22:29 2001
@@ -33,6 +33,71 @@
     X = 10
   end
 
+
+
+Options for Basic Namespace Representation
+------------------------------------------
+
+ * Add <block>.field, <form>.<block>.<field>, <block>, <field>, etc 
+   to namespace, and have a set of reserved words (properties, values,
+   etc) to prevent namespace collisions.
+   
+     Advantages: 
+       + Easiest to implement
+       + Code will be fairly clean looking (readability)
+       + Honors spirit of "objects"
+       + Typical approach taken by most products in similar situation
+   
+     Disadvantages:
+       + Places a larger burden on the end user as they must know and
+         avoid reserved words. 
+       + The reserved word list can (will?) grow, which could break 
+         pre-existing triggers as our specification grows.
+       + Only languages with support for object-oriented concepts can 
+         be embedded.
+       
+
+ * Add <block>.fields.<field> to namespace
+ 
+     Advantages:
+       + Easy to implement
+       + Less namespace conflict than above method
+       
+     Disadvantages:
+       + Since there will still be namespace conflicts, all of the 
+         previous disadvantages still apply. 
+       + Code will be harder to read
+     
+ * reference("block.field")
+   
+     Advantages:
+       + Will work in any language supporting functions (all?)
+       + Easier to implement as only a few methods need to be added to an
+       embedded language's namespace. 
+       
+     Disadvantages:
+       + Creates UGLY code ('nuff said?)
+
+     Notes:
+       + Perhaps this should be the preferred implementation for non-object
+         languages (scheme, etc) if an object-specific implementation is
+        selected
+
+ * Pre-parsing tokens (:block.field)
+ 
+     Advantages: 
+       + Creates a consistent markup for all supported languages.
+     
+     Disadvantages: 
+       + Depending on complexity, we may be creating a language on top of a
+         language
+       + 
+       + The complexity of writing a pre-parser has yet to be determined
+
+     Notes:
+       sum(:main.token)
+       setProperty(:main.token, 'Property','value')
+       
 *** Possible layout ***
 
 triggerManager
@@ -58,6 +123,5 @@
   
 triggerExtension
   adds ability to run triggers to objects that inherit it
-