[cvs] [Wiki] changed: RampageFramework

[Chuck Hagenbuch]

chuck  Sat, 23 Jul 2005 21:19:13 -0700

Modified page: http://wiki.horde.org/RampageFramework
New Revision:  1.5
Change log:  continuing updates

@@ -17,9 +17,9 @@
 * one database, pear installed files, one VFS space - have just one installed set of libs for multiple sites. do with HORDE_BASE or something similar?
 * differentiate between rampage app core (replace giapeto?) and libraries. try to go with more libraries than monolithic framework?
 * Context::appname::method($params) - this doesn't work, Rampage::app->method would. Already implemented in Registry class.
 * Session object for managing data we expect to find in $_SESSION
-* base Rampage on: ulaform, giapeto, wicked, should replace those ... ? what else?
+* base Rampage on: ulaform, giapeto, wicked, should replace those ... ? jonah?
 * Iterators! Only loop through data once!
 
 Encapsulated globals in Rampage:: namespace. Goal to avoid global $conf, $prefs, etc. variables and to do lazy-loading of conf and prefs so they're not loaded when they're not needed. Maybe encapsulate prefs in a User object/namespace?
 
@@ -36,12 +36,11 @@
 Pages/?
 Config/?
   xml files
 
-Catalyst::message()
- replaces logMessage(), fatal, notification, and observer
-  - has a return value!
- use extensions somehow, too?
+Rampage::log() - just for admin messages
+Rampage::message() or Rampage::notify()
+For user level notification - html alerts, ajax, send email, jabber, etc. Can be triggered by an Observer but doesn't implement object relationshps. What should? Workflow...
 
 ++ RDO
 
 Data dictionary - description of fields, basis for validation? required, etc... pull some from database, some from object hardcoded metadata?
@@ -56,10 +55,9 @@
 
 take interfaces that implement Iterator wherever possible
 
 need basic classes for each backend (SQL, LDAP, Kolab, IMSP, etc) that provide a unified api
-try hard not to use more than that api; write specific adapters when necessary (WhupsBackend implemented
-by WhupsBackend_sql, etc.).
+try hard not to use more than that api; write specific adapters when necessary (Whups with encapsulated specialized Mapper objects, etc.).
 
 ++ Display and templates
 
 - Fields