The WFPage encapsulates the UI and Controller Layer state of a page.
The Page infrastructure initializes pages by instantiating all WFView instances (including widgets) in a page (from the .instances file), loads all configs for those instances (from the .config file), and also can render the page to HTML using a WFPageRendering-compatible template instance.
The page manages the WFView instances with a Mediator pattern.
The page is responsible for helping the widgets restore their state from a request.
SEE COMPOSITE PATTERN IN GoF for ideas about the widget hierarchy.
WFPage automatically adds a few useful variables to your template:
Located in /framework/WFPage.php (line 160)
WFObject | --WFPage
Add an error to the current page.
This function is used by WFWidgets or from action methods to add errors to the current request page. Widgets automatically register all errors generated by Key-Value Validation of bound values. Clients can call this function from the action method to add other run-time errors to the error mechanism.
If the requestPage has *any* errors, the responsePage will *not* be loaded.
Add an instance to our page.
Use this function to add dynamically created instances to the page. NOTE: for adding WFView instances, you don't need to do this as the WFView class automatically registers all widgets.
Ensure the page is inited.
Assign a value to the underlying template engine.
Get the WFPageDelegate for this page.
Debug function for dumping the instance tree for the page.
Recursive. Call dumpTree() to use.
Get a list of all errors on the page.
Is the form valid? A form (ie requestPage submission) is considered valid if there are NO errors after it has been processed.
Determine if there is a page instance for the given id.
Does this page have a form that was submitted for it?
Handle the instantiation of the passed object from the instances file.
The .instances mechanism simply looks for a file named <pageName>.instances and a <pageName>.config file in your module's templates directory. The .instances contains a list of all WFView instances for the page, and the hierarchy information.
For each instance id, an instance of the listed class will be added to the view hierarchy. If children are listed, they will be added as well at the appropriate place in the hierarchy.
Handle the instantiation of the passed object from the .yaml file.
The .yaml mechanism simply looks for a file named <pageName>.yaml in your module's templates directory. The .your contains a list of all WFView instances for the page, in a hierarchical tree, and the configuration / binding information for each instance.
For each instance id, an instance of the listed class will be added to the view hierarchy. If children are listed, they will be added as well at the appropriate place in the hierarchy.
Initialize the named page. This will load the widget instances and prepare for manipulating the UI.
Each page has two parts, the HTML template, and the page instances config file (also called the .yaml file). On the filesystem, they are named <pageName>.tpl (the template file) and <pageName>.yaml (the config file).
Once the instances are initialized and configured, the module will be given a chance to load default settings for the page via a callback. This is the time to set up select lists, default values, etc. The method name that will be called on the module is "<pageName>_PageDidLoad". Here is the prototype for that method: void <pageName>_PageDidLoad($page, $parameters);
The parameters argument is an associative array, with "name" => "value". The items that will be in the array are determined by the page's parameterList, which is provided by the <pageName>_ParameterList() method, you can implement if your page needs parameters. This method should simply return a list of strings, which will become the "names" passed into your _PageDidLoad method.
Here's how the parameterization works... for each item in the array, first the PATH_INFO is mapped to the items. So, if your parameterList is:
array('itemID', 'otherParameter')
And the PATH_INFO is /12/moreData then the parameters passed in will be array('itemID' => '12', 'otherParameter' => 'moreData'). Any data that cannot be matched up will be passed with a NULL value. Also, if there is a form submitted, then the values for the parameters will be replaced by the "value" of the outlets of the same name. Thus, if your form has an "itemID" hidden field, the value from the form will supercede the value from PATH_INFO.
After the _PageDidLoad call, the UI state from the request will be applied on top of the defaults.
Get all instances of the page.
Has the page been loaded? This becomes true once initPage() is called.
Is this instance the requestPage for the module?
Is this instance the responsePage for the module?
Load the .config file for the page and process it.
The .config file is an OPTIONAL component. If your page has no instances, or the instances don't need configuration, you don't need a .config file. The .config file is used to set up 'properties' of the WFView instances AND to configure the 'bindings'.
Only primitive value types may be used. String, boolean, integer, double, NULL. NO arrays or objects allowed.
NOTE: To see what bindings and options are available for a widget, cd to /framework and run "php showBindings.php WFWidgetName".
Get the module that the page is a part of.
Get a reference to an instance of the page.
Using $page->outlet($id) is equivalent to accessing an object through a Cocoa outlet.
Get the name of the "page" for the current WFPage instance. The "page" is our equivalent of a nib file, essentially.
Get a named parameter.
Get the parameters for the page. These are the parsed parameters of the URL, coalesced with form elements of the same name.
NOTE: This data isn't available until after initPage() has executed.
Make sure a template object (a template engine conforming to WFPageRendering interface) is initialized.
For each widget in the current form, give the widget a chance to PULL the values from the bound objects onto the bound properties.
Only meaningful when called on the responsePage of the module. pullBindings() will call the pullBindings() method on all widgets in the form, thus allowing them to determine which bound properties need to "lookup" their values from the bound objects.
For each widget in the current form, give the widget a chance to PUSH the values from the form onto the bound objects.
Only meaningful when called on the requestPage of the module. pushBindings() will call the pushBindings() method on all widgets in the form, thus allowing them to determine which bound properties need to "publish" their values from the form onto the bound objects. If the value has changed, validate the value and set it as appropriate (on the bound object). WFWidget subclasses do that from their pushBindings() callback using propagateValueToBinding()
Remove an instance from the page.
Useful for dynamically created instances, if one needs to re-create them.
Get the HTML output of the page.
This function will call the <pageName>_SetupSkin() callback IFF this page belongs to the root module. This function is useful if a page wants to munge skin settings such as Title or Meta Info. It is called just prior to rendering the page, as this way the client can be certain that all data is loaded prior to this call.
The prototype is:
void <pageName>_SetupSkin($skin)
Restore the UI state of the page based on the submitted form.
Only meaningful when called on the requestPage of the module. Restore state will call the restoreState() method on all widgets in the form, thus allowing them to re-create the state they should be in after the changes that the user made to the form. IMPORTANT!!! THIS FUNCTION ONLY RESTORES THE VALUE OF THE UI WIDGET AND DOES NOT PUBLISH THE VALUE BACK THROUGH BINDINGS.
Set the WFPageDelegate to use for this page.
Tell the page to use an alternate .tpl file (besides the default, '<pagename>.tpl') for rendering the page.
When responding to a request, you will form a response to send back to the client. Depending on the nature of the response, there are two options in PHOCOA for building the response page.
In many cases, your application will need to present the same data in different ways. Once example of this is on "thank you" pages for contact form submissions. Since you will display the same data in the page, but display it differently, it is a good application of setTemplateFile().
The alternative is to use $module->setupResponsePage() to have PHOCOA respond to the request with a completely different page. However, this is most useful only if you are going to be displaying different data from the request. For instance, the "continue shopping" button of a shopping cart may go back to a product list page.
Convenience function to make it less verbose to get access to a shared outlet from a $page object (usually from a WFPageDelegate method).
Determine the name of the submitted form, if there is a submitted form for the current module.
This function takes into account the module invocation's respondsToForms setting...
Get a URL that will take you to the current requestPage of the module, with the current state.
Only meaningful when called on the requestPage of the module.
Get a list of all instantiated widgets belonging to this page.
Inherited From WFObject
WFObject::__construct()
WFObject::exposedProperties()
WFObject::getClass()
WFObject::keyPathToTargetAndKey()
WFObject::setValueForKey()
WFObject::setValueForKeyPath()
WFObject::validateValueForKey()
WFObject::validateValueForKeyPath()
WFObject::valueForKey()
WFObject::valueForKeyPath()
WFObject::valueForUndefinedKey()
WFObject::__toString()
Documentation generated on Thu, 17 Apr 2008 13:51:59 -0400 by phpDocumentor 1.4.1