[cvs] [Wiki] changed: RampageFramework

[Chuck Hagenbuch]

chuck  Sun, 06 Nov 2005 14:41:42 -0800

Modified page: http://wiki.horde.org/RampageFramework
New Revision:  11.4
Change log:  fix a spelling error and surpress wiki words that aren't

@@ -122,17 +122,17 @@
 App/Method/Params?
 
 ++ RSS
 
-FeedBuilder - strategy interface for building multiple kinds of feeds (atom, rss versions, etc.) Takes any object that implements a Feedable interface, or a result set that implements FeedableCollection. Should RDO_Result implement that? Or should we use a more general Describable interface, like below?
+!FeedBuilder - strategy interface for building multiple kinds of feeds (atom, rss versions, etc.) Takes any object that implements a Feedable interface, or a result set that implements !FeedableCollection. Should RDO_Result implement that? Or should we use a more general Describable interface, like below?
 
 ++ FormBuilder
 
 Interface with different form building implementations.
-takes an RDO_ResultSet or a single RDO object and builds a form based on that (array is for row based renderers, etc). Or use a more general Describable interface. Need anything besides describe()? Have a DescribableCollection, too, and have RDO_ResultSet implement that?
+takes an RDO_ResultSet or a single RDO object and builds a form based on that (array is for row based renderers, etc). Or use a more general Describable interface. Need anything besides describe()? Have a !DescribableCollection, too, and have RDO_ResultSet implement that?
 
-RampageObject
-DescriableObject
+!RampageObject
+!DescribableObject
   |- describe()
 
 ++ Example Applications
 
@@ -156,9 +156,9 @@
 Money amount = ...;
 //...
 value       =  amount.getValue();
 currency    =  amount.getCurrency();
-conversion  =  CurrencyTable.getConversionFactor( currency, USDOLLARS );
+conversion  =  !CurrencyTable.getConversionFactor( currency, USDOLLARS );
 total       += value * conversion;
 //...
 
 This change is too complicated to be handled by automated refactoring. Moreover, you would have to make these sorts of changes everywhere in your code.
@@ -169,9 +169,9 @@
 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.)
+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
 
 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.