[cvs] [Wiki] changed: RampageFramework

[Chuck Hagenbuch]

chuck  Sat, 23 Jul 2005 21:06:09 -0700

Modified page: http://wiki.horde.org/RampageFramework
New Revision:  1.4
Change log:  updates and new thoughts

@@ -1,40 +1,33 @@
-next-gen Horde
-- Views/
-- Forms/ dir in apps
-- next-gen !DataTree - !DataObject ?
-- php5
-- Fields
-- html/xhtml/xml renderers
-- php5 xsl?
-- Context::appname::method($params)
++ Rampage - next gen horde php5 app-building framework
 
-Catalyst - next gen horde app-building framework
-AJAx builtin
+//get PEAR channel up for Horde so new code can be distributed!//
+
+[[toc]]
+
+++ General ideas
+
+AJAX built-in
 webservices
-Context object
+Context object?
 see ruby on rails and DB_DataObject pdf
-- all config in a sqlite core db
-- !FrontController pattern
-- integrate w/ existing Horde
-- one database, pear installed files, one VFS space
-- templated
-
-Encapsulated globals in Catalyst:: namespace
+* all config in a sqlite core db - not sure about this
+* next-gen !DataTree - RDO. Need a seperate tree/hierarchy solution
+* Controller patterns - not necessarily a front controller, files already are that. unified /path/app/item/id would be good.
+* integrate w/ existing Horde
+* 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?
+* Iterators! Only loop through data once!
 
-webroot contains:
- index.php
- .htaccess
- themes/
- js/
+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?
 
 everything else pear installable
-- apps
-- blocks
+- apps - Horde/Rampage/App/Appname, or Apps?
+- blocks - Horde/Rampage/Block/, or Horde/Block?
 - libs
-
-Apps are installed under:
-Horde/Catalyst/Apps/Foo
 
 Each app has:
 Views/
 Forms/
@@ -42,41 +35,19 @@
 Methods/
 Pages/?
 Config/?
   xml files
-
-
-!ViewBuilder/!PageBuilder custom views
-Web services, command line, GET/web layout should be identical
-App/Method/Params?
 
 Catalyst::message()
  replaces logMessage(), fatal, notification, and observer
   - has a return value!
  use extensions somehow, too?
 
-Session object for managing data we expect to find in $_SESSION
-
-base catalyst on: ulaform, giapeto, wicked, should replace those ... ? what else?
-
-Iterators! Only loop through data once!
+++ RDO
 
+Data dictionary - description of fields, basis for validation? required, etc... pull some from database, some from object hardcoded metadata?
 
 Use Turba as basis for RDO_Storage objects
-
-get PEAR channel up for Horde so new code can be distributed.
-
-
-
-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.).
-
-
-
-Task object
-
-returned by any of the DA backends (table gateway? row gateway? data mapper?) - Mapper.
 
 no set/get
 just pass it a $form object
 commands come in somewhere
@@ -84,17 +55,25 @@
 http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html - Listing 0.1.Elim... !
 
 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.).
 
-MVC is 30 years old
+++ Display and templates
 
+- Fields
+- html/xhtml/xml renderers
+- php5 xsl?
 
+!ViewBuilder/!PageBuilder custom views
+Web services, command line, GET/web layout should be identical
+App/Method/Params?
 
-Data dictionary - description of fields, basis for validation? required, etc... pull some from database ala
-ActiveRecord?
-
+++ Things to remember
 
+MVC is 30 years old
 
 double orderTotal;
 Money amount = ...;
 //...
@@ -117,17 +96,16 @@
 Money total  = ...;
 Money amount = ...;
 
 total.increaseBy( amount );
-
 
 FlowLayoutPanel, GridLayoutPanel, BorderLayoutPanel, etc., but that mandates too many classes and a lot of duplicated code in those classes. A single heavyweight-class solution (adding methods to Container like layOutAsGrid(), layOutAsFlow(), etc.) is also impractical because you can't modify the source code for the Container simply because you need an unsupported layout. In the Strategy pattern, you create a Strategy interface (LayoutManager) implemented by several Concrete Strategy classes (FlowLayout, GridLayout, etc.). You then tell a Context object (a Container) how to do something by passing it a Strategy object. (You pass a Container a LayoutManager that defines a layout strategy.)
 
+Frameworks
 
- Frameworks
 A discussion of fragile base classes would be incomplete without a mention of framework-based programming. Frameworks such as Microsoft Foundation Classes (MFC) have become a popular way of building class libraries. Though MFC itself is blessedly fading away, MFC's structure has been ingrained in countless Microsoft shops where programmers assumed that the Microsoft way was the best way.
 
 A framework-based system typically starts with a library of half-baked classes that don't do everything they need to do, but rather rely on a derived class to provide missing functionality. A good example in Java is the Component's paint() method, which is effectively a place holder; a derived class must provide the real version.
 
 You can get away with this sort of thing in moderation, but an entire class framework that depends on derivation-based customization is brittle in the extreme. The base classes are too fragile. When I programmed in MFC, I had to rewrite all my applications every time Microsoft released a new version. The code would often compile, but then not work because some base-class method changed.
 
-All Java packages work quite well out of the box. You don't need to extend anything to make them function. This works-out-of-the-box structure is better than a derivation-based framework. It's easier to maintain and use, and doesn't put your code at risk if a Sun Microsystems-supplied class changes its implementation. 
+All Java packages work quite well out of the box. You don't need to extend anything to make them function. This works-out-of-the-box structure is better than a derivation-based framework. It's easier to maintain and use, and doesn't put your code at risk if a Sun Microsystems-supplied class changes its implementation.