\documentclass{article} \usepackage{ulem} \usepackage{graphicx} \usepackage{hyperref} \pagestyle{headings} \begin{document} \part{Horde on the Rampage} \section{Rampage Libraries} These are PHP 5.2+ libraries, in some cases PHP 5.3+, that are E\_STRICT compliant, that will be part of Horde 4 and the Rampage framework: \begin{itemize} \item Horde/Argv \item Horde/Feed \item Horde/Http\_Client \item Horde/Lens \item Horde/Log \item Horde/Pdf \item Horde/Rdo \item Horde/Routes \item Horde/Text\_Rst \item Horde/Text\_Textile \item Horde/View \item Horde/Xml\_Element \item Horde/Yaml \end{itemize} \section{General ideas} \subsection{RampageInstallation} \subsection{Lightweight component architecture} Take a look at the Horde\_Block system. Take a look at the *\_View objects in Kronolith and a few other apps. Come up with something that unifies them into a lightweight way to encapsulate content in an easy-to-reuse, easy-to-render elsewhere package. \subsection{Structure} New structure for views/commands: /do/App/Command
/get/App/View AJAX built-in
webservices
Context object?
see ruby on rails and DB\_DataObject pdf \begin{itemize} \item all config in a sqlite core db - not sure about this \item next-gen DataTree - RDO. Need a seperate tree/hierarchy solution \item Controller patterns - not necessarily a front controller, files already are that. unified /path/app/item/id would be good. \item integrate w/ existing Horde \item 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? \item differentiate between rampage app core (replace giapeto?) and libraries. try to go with more libraries than monolithic framework? \item Context::appname::method(\$params) - this doesn't work, Rampage::app->method would. Already implemented in Registry class. \item Session object for managing data we expect to find in \$\_SESSION \item base Rampage on: ulaform, giapeto, wicked, should replace those ... ? jonah? \item Iterators! Only loop through data once! \item Page/URL design: the back button should work where possible \item use POST for anything that's an edit or delete. really. \item Make use of stream wrappers for easy fopen/fwrite/fgets with data sources. VFS wrappers at least. \end{itemize} 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 \begin{itemize} \item apps - Horde/Rampage/App/Appname, or Apps? \item blocks - Horde/Rampage/Block/, or Horde/Block? \item libs \end{itemize} Each app has:
Views/
Forms/
Objects/
Methods/
Pages/?
Config/?
xml files Dir structure for distributable apps: www.sitename.tld
cron/
htdocs/
.htaccess
themes/
screen.css
graphics/
sounds/
javascript/
index.php
includes/
pear/ ?
logs/
scripts/
templates/ Use .phar (php archive) files for installing rampage sites? 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... \section{RDO} Data dictionary - description of fields, basis for validation? required, etc... pull some from database, some from object hardcoded metadata? no set/get
just pass it a \$form object
commands come in somewhere
Builder: http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox-p2.html
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 (Whups with encapsulated specialized Mapper objects, etc.). Should be a way to cache table meta data Need a way to specify which fields to load (for example like Turba only loads fields being displayed). When this is done, the rest should be lazy-loaded. Should be possible to greedy-load related objects (lazy is the default). \section{Display and templates, Views and Components} \begin{itemize} \item views/components should be nestable \item need a concept of "slots" - where can a view put sub-views \item copy java's layout managers? or is that too heavy? want to keep it simple \item How much effort should be put into formats other than XHTML? probably different for data vs. components. Data should be available as a pdf, as rss feeds, in export formats. Components will still be xhtml, maybe wml for mobile device support, maybe php-gtk - more limited set. \item Fields \item html/xhtml/xml renderers \end{itemize} \subsection{What's good about Horde\_Template} \begin{itemize} \item simple \end{itemize} \subsection{What's bad about Horde\_Template} \begin{itemize} \item does not result in valid XML templates because of nested < inside tags () \item hard to debug \item actually not so fast \item no built-in support for htmlspecialchars(), so the code using the template has to know what to encode \end{itemize} Replace with: \begin{itemize} \item http://solarphp.com/trac/browser/trunk/Solar/View.php or similar View pattern \item http://www.phpwact.org/pattern/template\textbackslash\{\}\_view \end{itemize} !ViewBuilder/PageBuilder custom views
Web services, command line, GET/web layout should be identical
App/Method/Params? \section{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? \section{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? RampageObject
DescribableObject
|- describe() \section{Example Applications} \begin{itemize} \item tagging/category-based bookmarks \& blog apps? \end{itemize} \section{Things to remember} MVC is 30 years old A rant on installing software: http://www.lastcraft.com/blog/index.php?p=11
Top Ten website mistakes: http://www.useit.com/alertbox/990502.html double orderTotal;
Money amount = ...;
*...
orderTotal += amount.getValue(); * orderTotal must be in dollars The problem with this approach is that the foregoing code makes a big assumption about how the Money class is implemented (that the "value" is stored in a double). Code that makes implementation assumptions breaks when the implementation changes. If, for example, you need to internationalize your application to support currencies other than dollars, then getValue() returns nothing meaningful. You could add a getCurrency(), but that would make all the code surrounding the getValue() call much more complicated, especially if you persist in using the getter/setter strategy to get the information you need to do the work. A typical (flawed) implementation might look like this: Money amount = ...;
*...
value = amount.getValue();
currency = amount.getCurrency();
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. The business-logic-level solution to this problem is to do the work in the object that has the information required to do the work. Instead of extracting the "value" to perform some external operation on it, you should have the Money class do all the money-related operations, including currency conversion. A properly structured object would handle the total like this: Money total = ...;
Money amount = ...; total.increaseBy( amount ); 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. 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. \end{document}