[cvs] [Wiki] changed: RampageFramework

[Wiki Guest]

guest [65.19.150.231]  Sun, 21 Aug 2005 20:08:57 -0700

Modified page: http://wiki.horde.org/RampageFramework
New Revision:  6.0
Change log:  Revert

@@ -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 ... ? jonah?
+* base Rampage on: ulaform, giapeto, wicked, should replace those ... ? what else?
 * 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,11 +36,12 @@
 Pages/?
 Config/?
   xml files
 
-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...
+Catalyst::message()
+ replaces logMessage(), fatal, notification, and observer
+  - has a return value!
+ use extensions somehow, too?
 
 ++ RDO
 
 Data dictionary - description of fields, basis for validation? required, etc... pull some from database, some from object hardcoded metadata?
@@ -55,9 +56,10 @@
 
 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 (Whups with encapsulated specialized Mapper objects, etc.).
+try hard not to use more than that api; write specific adapters when necessary (WhupsBackend implemented
+by WhupsBackend_sql, etc.).
 
 ++ Display and templates
 
 - Fields