Permalink
Browse files

Small text changes, added api links, cont. updating images for tutori…

…als, fixed tutorials from member feedback
  • Loading branch information...
1 parent e9f20cf commit f3ac57394d3e1f7e6003d5b32d409ddba68900b8 Michael Andrewartha committed with chillu Mar 8, 2011
Showing with 718 additions and 643 deletions.
  1. +1 −1 docs/en/reference/advanced-templates.md
  2. +1 −1 docs/en/reference/bbcode.md
  3. +1 −1 docs/en/reference/built-in-page-controls.md
  4. +10 −10 docs/en/reference/complextablefield.md
  5. +12 −12 docs/en/reference/database-structure.md
  6. +5 −7 docs/en/reference/dataobject.md
  7. +13 −13 docs/en/reference/dataobjectdecorator.md
  8. +3 −3 docs/en/reference/dataobjectset.md
  9. +5 −5 docs/en/reference/director.md
  10. +2 −2 docs/en/reference/execution-pipeline.md
  11. +1 −1 docs/en/reference/form-field-types.md
  12. +2 −2 docs/en/reference/image.md
  13. +1 −1 docs/en/reference/index.md
  14. +12 −11 docs/en/reference/member.md
  15. +1 −1 docs/en/reference/modeladmin.md
  16. +2 −4 docs/en/reference/partial-caching.md
  17. +3 −3 docs/en/reference/permission.md
  18. +1 −2 docs/en/reference/requirements.md
  19. +8 −7 docs/en/reference/restfulservice.md
  20. +4 −4 docs/en/reference/rssfeed.md
  21. +7 −11 docs/en/reference/searchcontext.md
  22. +5 −7 docs/en/reference/site-reports.md
  23. +7 −8 docs/en/reference/siteconfig.md
  24. +9 −9 docs/en/reference/sqlquery.md
  25. +4 −4 docs/en/reference/staticpublisher.md
  26. +8 −9 docs/en/reference/tablefield.md
  27. +12 −12 docs/en/reference/tablelistfield.md
  28. +6 −8 docs/en/reference/typography.md
  29. +9 −9 docs/en/reference/urlvariabletools.md
  30. +1 −3 docs/en/reference/versioned.md
  31. +16 −12 docs/en/topics/access-control.md
  32. +7 −6 docs/en/topics/configuration.md
  33. +14 −14 docs/en/topics/controller.md
  34. +3 −2 docs/en/topics/css.md
  35. +3 −3 docs/en/topics/data-types.md
  36. +33 −35 docs/en/topics/datamodel.md
  37. +4 −4 docs/en/topics/debugging.md
  38. +3 −3 docs/en/topics/directory-structure.md
  39. +8 −8 docs/en/topics/email.md
  40. +14 −14 docs/en/topics/environment-management.md
  41. +6 −5 docs/en/topics/error-handling.md
  42. +5 −7 docs/en/topics/extending-the-cms.md
  43. +2 −2 docs/en/topics/form-validation.md
  44. +7 −4 docs/en/topics/forms.md
  45. +10 −6 docs/en/topics/i18n.md
  46. +3 −3 docs/en/topics/index.md
  47. +8 −6 docs/en/topics/javascript.md
  48. +6 −3 docs/en/topics/module-development.md
  49. +5 −0 docs/en/topics/modules.md
  50. +7 −6 docs/en/topics/page-types.md
  51. +6 −3 docs/en/topics/search.md
  52. +12 −11 docs/en/topics/security.md
  53. +2 −2 docs/en/topics/templates.md
  54. +3 −5 docs/en/topics/testing/create-functional-test.md
  55. +5 −5 docs/en/topics/testing/create-sapphire-test.md
  56. +3 −3 docs/en/topics/testing/email-sending.md
  57. +13 −10 docs/en/topics/theme-development.md
  58. +1 −1 docs/en/topics/themes.md
  59. +48 −36 docs/en/topics/translation.md
  60. +41 −33 docs/en/topics/widgets.md
  61. +2 −2 docs/en/tutorials/2-extending-a-basic-site.md
  62. +64 −1 docs/en/tutorials/4-site-search.md
  63. +198 −217 docs/en/tutorials/5-dataobject-relationship-management.md
  64. BIN docs/en/tutorials/_images/gsoc-mentor-creation.jpg
  65. BIN docs/en/tutorials/_images/gsoc-mentor-student-selection.jpg
  66. BIN docs/en/tutorials/_images/gsoc-mentor.jpg
  67. BIN docs/en/tutorials/_images/gsoc-module-creation.jpg
  68. BIN docs/en/tutorials/_images/gsoc-project-creation.jpg
  69. BIN docs/en/tutorials/_images/gsoc-project-module-selection.jpg
  70. BIN docs/en/tutorials/_images/gsoc-project-student-selection.jpg
  71. BIN docs/en/tutorials/_images/gsoc-project.jpg
  72. BIN docs/en/tutorials/_images/gsoc-projects-table.jpg
  73. BIN docs/en/tutorials/_images/gsoc-student-creation.jpg
  74. BIN docs/en/tutorials/_images/searchform-small.jpg
  75. BIN docs/en/tutorials/_images/searchform.jpg
  76. BIN docs/en/tutorials/_images/searchresults-small.jpg
  77. BIN docs/en/tutorials/_images/searchresults.jpg
  78. BIN docs/en/tutorials/_images/tutorial5-completecode-blackcandy.zip
  79. BIN docs/en/tutorials/_images/tutorial5-completecode.zip
@@ -406,7 +406,7 @@ to debug.
## Related
* [Templates](/topics/templates)
* [Themes](/topics/themes)
-* [Developing Themes](theme-development)
+* [Developing Themes](/topics/theme-development)
* [Widgets](/topics/widgets)
* [Images](/reference/image)
* [Built in page controls](/reference/built-in-page-controls)
@@ -9,7 +9,7 @@ BBCode is used by default in the [blog](http://silverstripe.org/blog-module) and
To add bbcode parsing to a template, instead of $Content use:
- :::php
+ :::ss
$Content.Parse(BBCodeParser)
@@ -60,7 +60,7 @@ SilverStripe supports a simple set of conditional logic
<% end_if %>
-See more information on conditional logic on [templates](templates).
+See more information on conditional logic on [templates](/topics/templates).
### Site wide settings
@@ -15,7 +15,7 @@ See `[api:TableListField]`.
## Setting Parent/Child-Relations
-ComplexTableField tries to determine the parent-relation automatically by looking at the $has_one property on the listed
+`[api:ComplexTableField]` tries to determine the parent-relation automatically by looking at the $has_one property on the listed
child, or the record loaded into the surrounding form (see getParentClass() and getParentIdName()). You can force a
specific parent relation:
@@ -62,18 +62,18 @@ You can override this behaviour in various ways:
If you don't want several functions to appear (e.g. no add-link), there's several ways:
-* Use ComplexTableField->setPermissions(array("show","edit")) to limit the functionality without touching the template
+* Use `ComplexTableField->setPermissions(array("show","edit"))` to limit the functionality without touching the template
(more secure). Possible values are "show","edit", "delete" and "add".
-* Subclass ComplexTableField and override the rendering-mechanism
-* Use ComplexTableField->setTemplate() and ComplexTableField->setTemplatePopup() to provide custom templates
+* Subclass `[api:ComplexTableField]` and override the rendering-mechanism
+* Use `ComplexTableField->setTemplate()` and `ComplexTableField->setTemplatePopup()` to provide custom templates
### Customising fields and Requirements in the popup
There are several ways to customise the fields in the popup. Often you would want to display more information in the
popup as there is more real-estate for you to play with.
-ComplexTableField gives you several options to do this. You can either
+`[api:ComplexTableField]` gives you several options to do this. You can either
* Pass a FieldSet in the constructor.
* Pass a String in the constructor.
@@ -83,7 +83,7 @@ The second will call the String as a method on the source class (Which should re
Popup.
You can also customise Javascript which is loaded for the Lightbox. As Requirements::clear() is called when the popup is
-instantiated, ComplexTableField will look for a function to gather any specific requirements that you might need on your
+instantiated, `[api:ComplexTableField]` will look for a function to gather any specific requirements that you might need on your
source class. (e.g. Inline Javascript or styling).
For this, create a function called "getRequirementsForPopup".
@@ -116,11 +116,11 @@ You'll have to do something like this in your form:
You have to hack in an ID on the form, as the CMS forms have this, and front end forms usually do not.
-It's not a perfect solution, but it works relatively well to get a simple ComplexTableField up and running on the front
+It's not a perfect solution, but it works relatively well to get a simple `[api:ComplexTableField]` up and running on the front
end.
To come: Make it a lot more flexible so tables can be easily used on the front end. It also needs to be flexible enough
-to use a popup as well, out of the box.
+to use a popup as well, out of the box.
## Subclassing
@@ -144,7 +144,7 @@ Most of the time, you need to override the following methods:
* Find a less fragile solution for accessing this field through the main controller and ReferencedField, e.g. build a
seperate CTF-instance (doesn't necessarly have to be connected to the original by ReferencedField)
* Control width/height of popup by constructor (hardcoded at the moment)
-* Integrate search from MemberTableField.php directly on ComplexTableField
+* Integrate search from MemberTableField.php directly on `[api:ComplexTableField]`
* Less performance-hungry implementation of detail-view paging (don't return all items on a single view)
* Use automatic has-many and many-many functions to return a ComponentSet rather than building the join manually
-* Javascript/Ajax-Sorting (see http://www.activewidgets.com/grid/ and http://openrico.org/rico/livegrid.page)
+* Javascript/Ajax-Sorting (see [http://www.activewidgets.com/grid/](http://www.activewidgets.com/grid/) and [http://openrico.org/rico/livegrid.page](http://openrico.org/rico/livegrid.page))
@@ -5,7 +5,7 @@ opting for "convention over configuration". This page details what that databas
## Base tables
-Each direct sub-class of DataObject will have its own table.
+Each direct sub-class of `[api:DataObject]` will have its own table.
The following fields are always created.
@@ -36,21 +36,21 @@ data sub-classed objects across **multiple tables**.
For example, suppose we have the following set of classes:
-* Class SiteTree extends DataObject: Title, Content fields
-* Class Page extends SiteTree: Abstract field
-* Class NewsSection extends SiteTree: *No special fields*
-* Class NewsArticle extend Page: ArticleDate field
+* Class `[api:SiteTree]` extends `[api:DataObject]`: Title, Content fields
+* Class `[api:Page]` extends `[api:SiteTree]`: Abstract field
+* Class NewsSection extends `[api:SiteTree]`: *No special fields*
+* Class NewsArticle extend `[api:Page]`: ArticleDate field
The data for the following classes would be stored across the following tables:
-* SiteTree
+* `[api:SiteTree]`
* ID: Int
* ClassName: Enum('SiteTree', 'Page', 'NewsArticle')
* Created: Datetime
* LastEdited: Datetime
* Title: Varchar
* Content: Text
-* Page
+* `[api:Page]`
* ID: Int
* Abstract: Text
* NewsArticle
@@ -59,16 +59,16 @@ The data for the following classes would be stored across the following tables:
The way it works is this:
-* "Base classes" are direct sub-classes of DataObject. They are always given a table, whether or not they have special
-fields. This is called the "base table"
+* "Base classes" are direct sub-classes of `[api:DataObject]`. They are always given a table, whether or not they have
+special fields. This is called the "base table"
* The base table's ClassName field is set to class of the given record. It's an enumeration of all possible
sub-classes of the base class (including the base class itself)
* Each sub-class of the base object will also be given its own table, *as long as it has custom fields*. In the
example above, NewsSection didn't have its own data and so an extra table would be redundant.
* In all the tables, ID is the primary key. A matching ID number is used for all parts of a particular record:
-record #2 in Page refers to the same object as record #2 in SiteTree.
+record #2 in Page refers to the same object as record #2 in `[api:SiteTree]`.
-To retrieve a news article, SilverStripe joins the SiteTree, Page and NewsArticle tables by their ID fields. We use a
+To retrieve a news article, SilverStripe joins the `[api:SiteTree]`, `[api:Page]` and NewsArticle tables by their ID fields. We use a
left-join for robustness; if there is no matching record in Page, we can return a record with a blank Article field.
## Staging and versioning
@@ -126,4 +126,4 @@ other database platforms if we chose to support them.
* We'd like to support more than just MySQL, however, there needs to be a pretty good reason for doing so since it will
become something that needs to be supported for the rest of SilverStripe's life and could easily become an albatross.
On the cards are MS SQL, PostgreSQL and SQLite.
-* It could be desireable to implement a non-repeating auto-numbering system.
+* It could be desirable to implement a non-repeating auto-numbering system.
@@ -12,7 +12,7 @@ A single database record & abstract class for the data-access-model.
## Basics
-The call to `DataObject->getCMSFields()` is the centerpiece of every data administration interface in Silverstripe,
+The call to `DataObject->getCMSFields()` is the centerpiece of every data administration interface in SilverStripe,
which returns a `[api:FieldSet]`''.
:::php
@@ -33,8 +33,6 @@ These calls retrieve a `[api:FieldSet]` for the area where you intend to work wi
* Requirements: SilverStripe 2.3.*
-// bla
-
:::php
$fields = singleton('MyDataObject')->getCMSFields();
@@ -82,8 +80,8 @@ Example: Simple Definition
}
-Searchable fields will be appear in the search interface with a default form field (usually a TextField) and a default
-search filter assigned (usually an ExactMatchFilter). To override these defaults, you can specify additional information
+Searchable fields will be appear in the search interface with a default form field (usually a `[api:TextField]`) and a default
+search filter assigned (usually an `[api:ExactMatchFilter]`). To override these defaults, you can specify additional information
on `$searchable_fields`:
:::php
@@ -95,7 +93,7 @@ on `$searchable_fields`:
}
-If you assign a single string value, you can set it to be either a FormField or SearchFilter. To specify both, you can
+If you assign a single string value, you can set it to be either a `[api:FormField]` or `[api:SearchFilter]`. To specify both, you can
assign an array:
:::php
@@ -144,7 +142,7 @@ To include relations (''$has_one'', `$has_many` and `$many_many`) in your search
* Requirements: SilverStripe 2.3.*
-Summary fields can be used to show a quick overview of the data for a specific DataObject record. Most common use is
+Summary fields can be used to show a quick overview of the data for a specific `[api:DataObject]` record. Most common use is
their display as table columns, e.g. in the search results of a `[api:ModelAdmin]` CMS interface.
Example: Getting predefined summary fields
@@ -9,7 +9,7 @@ implementation. Have a look at `[api:Object->useCustomClass()]`.
## Usage
-Your Decorator will nee to be a subclass of DataObjectDecorator or the Extension class.
+Your Decorator will nee to be a subclass of `[api:DataObjectDecorator]` or the `[api:Extension]` class.
:::php
<?php
@@ -27,7 +27,7 @@ class you want to extend.
### Adding a decorator to a built-in class
Sometimes you will want to add decorators to classes that you didn't make. For example, you might want to add the
-ForumRole decorator to the Member object.
+`[api:ForumRole]` decorator to the `[api:Member]` object.
:::php
@@ -97,20 +97,20 @@ The $fields parameter is passed by reference, as it is an object.
### Custom database generation
-Some decorators are designed to transparently add more sophisticated data-collection capabilities to your data object.
-For example, Versioned adds version tracking and staging to any data object that it is applied to. To do this, you need
-to be able to create additional database tables and fields to keep your state stored in.
+Some decorators are designed to transparently add more sophisticated data-collection capabilities to your data object.
+For example, `[api:Versioned]` adds version tracking and staging to any data object that it is applied to. To do this,
+you need to be able to create additional database tables and fields to keep your state stored in.
To do this, define an **augmentDatabase()** method on your decorator. This will be called when db/build is visited.
-* You can query $this->owner for information about the data object, such as the fields it has
+* You can query ``$this->owner`` for information about the data object, such as the fields it has
* You can use **DB::requireTable($tableName, $fieldList, $indexList)** to set up your new tables. This function takes
care of creating, modifying, or leaving tables as required, based on your desired schema.
### Custom write queries
If you have customised the generated database, then you probably want to change the way that writes happen. This is
-used by Versioned to get an entry written in ClassName_versions whenever an insert/update happens.
+used by `[api:Versioned]` to get an entry written in ClassName_versions whenever an insert/update happens.
To do this, define the **augmentWrite(&$manipulation)** method. This method is passed a manipulation array representing
the write about to happen, and is able to amend this as desired, since it is passed by reference.
@@ -125,17 +125,17 @@ be modified as needed by your method. Instead of a manipulation array, we have
### Additional methods
-The other thing you may want to do with a decorator is provide a method that can be called on the DataObject that is
-being decorated. For instance, you may add a publish() method to every DataObject that is decorated with Versioned.
+The other thing you may want to do with a decorator is provide a method that can be called on the `[api:DataObject]` that is
+being decorated. For instance, you may add a publish() method to every `[api:DataObject]` that is decorated with `[api:Versioned]`.
This is as simple as defining a method called publish() on your decorator. Bear in mind, however, that instead of
$this, you should be referring to $this->owner.
-* $this = The DataObjectDecorator object.
-* $this->owner = The related DataObject object.
+* $this = The `[api:DataObjectDecorator]` object.
+* $this->owner = The related `[api:DataObject]` object.
-If you want to add your own internal properties, you can add this to the DataObjectDecorator, and these will be referred
-to as $this->propertyName. Every DataObject has an associated DataObjectDecorator instance for each class that it is
+If you want to add your own internal properties, you can add this to the `[api:DataObjectDecorator]`, and these will be referred
+to as `$this->propertyName`. Every `[api:DataObject]` has an associated `[api:DataObjectDecorator]` instance for each class that it is
decorated by.
:::php
@@ -6,7 +6,7 @@ This class represents a set of `[api:DataObject]`s, such as the results of a que
[datamodel](/topics/datamodel)-related querying. It implements the [Iterator
interface](http://php.net/manual/en/language.oop5.iterations.php) introduced in PHP5.
-Relations (`has_many`/`many_many`) are described in `[api:ComponentSet]`, a subclass of DataObjectSet.
+Relations (`has_many`/`many_many`) are described in `[api:ComponentSet]`, a subclass of `[api:DataObjectSet]`.
## Usage
@@ -56,7 +56,7 @@ This works on the object itself, so do NOT do something like this:
:::php
$sortedSet = $mySet->sort('Lastname'); //ascending
-## Merge with other DataObjectSets
+## Merge with other `[api:DataObjectSet]`s
:::php
$myFirstSet->merge($mySecondSet);
@@ -88,7 +88,7 @@ It is good practice to check for empty sets before doing any iteration.
### Paging
-DataObjects have native support for dealing with **pagination**.
+`[api:DataObject]`s have native support for dealing with **pagination**.
See *setPageLimits*, *setPageLength*, etc.
FIXME Complete pagination documentation
@@ -2,7 +2,7 @@
## Introduction
-Director is the first step in the "execution pipeline". It parses the URL, matching it to one of a number of patterns,
+`[api:Director]` is the first step in the "execution pipeline". It parses the URL, matching it to one of a number of patterns,
and determines the controller, action and any argument to be used. It then runs the controller, which will finally run
the viewer and/or perform processing steps.
@@ -12,7 +12,7 @@ the viewer and/or perform processing steps.
## Redirection
-The Director class has a number of methods to facilitate 301 and 302 HTTP redirection.
+The `[api:Director]` class has a number of methods to facilitate 301 and 302 HTTP redirection.
* **Director::redirect("action-name")**: If there's no slash in the URL passed to redirect, then it is assumed that you
want to go to a different action on the current controller.
@@ -33,8 +33,8 @@ redirectBack().
You can influence the way URLs are resolved one of 2 ways
-1. Adding rules to Director in `<yourproject>/_config.php` (See Default Rewrite Rules below for examples)
-2. Adding rules in your extended Controller class via the *$url_handlers* static variable
+1. Adding rules to `[api:Director]` in `<yourproject>/_config.php` (See Default Rewrite Rules below for examples)
+2. Adding rules in your extended `[api:Controller]` class via the *$url_handlers* static variable
See [controller](/topics/controller) for examples and explanations on how the rules get processed for both 1 and 2 above.
@@ -56,7 +56,7 @@ SilverStripe comes with certain rewrite rules (e.g. for *admin/assets*).
## Links
-* See ModelAsController class for details on controller/model-coupling
+* See `[api:ModelAsController]` class for details on controller/model-coupling
* See [execution-pipeline](/reference/execution-pipeline) for custom routing
## API Documentation
@@ -53,7 +53,7 @@ All requests go through main.php, which sets up the environment and then hands c
**See:** The API documentation of `[api:Main]` for information about how main.php processes requests.
## Director and URL patterns
-main.php relies on Director to work out which controller should handle this request. Director will instantiate that
+main.php relies on `[api:Director]` to work out which controller should handle this request. `[api:Director]` will instantiate that
controller object and then call `[api:Controller::run()]`.
**See:** The API documentation of `[api:Director]` for information about how Director parses URLs and hands control over to a controller object.
@@ -73,7 +73,7 @@ When you create a function, you can access the ID like this:
## Controllers and actions
-Controllers are the building blocks of your application.
+`[api:Controller]`s are the building blocks of your application.
**See:** The API documentation for `[api:Controller]`
@@ -48,7 +48,7 @@ set {inlcudeDefaultJS} to false and work with behaviour.js.
* `[FileField](api:FileField)`: Simple file upload dialog.
* `[FileIFrameField](api:FileIFrameField)`: File uploads through an iframe
-* `[api:Image]`: Image upload through an iframe, with thumbnails and file-selection from existing assets
+* `[api:ImageField]`: Image upload through an iframe, with thumbnails and file-selection from existing assets
* `[SimpleImageField](api:SimpleImageField)`: SimpleImageField provides an easy way of uploading images to Image has_one
relationships. Unlike ImageField, it doesn't use an iframe.
@@ -111,8 +111,8 @@ and whenever you upload or modify an Image through SilverStripe.
If you encounter problems with images not appearing, or have mysteriously disappeared, you can try manually flushing the
image cache.
-
+
http://www.mysite.com/images/flush
-
+
## API Documentation
`[api:Image]`
Oops, something went wrong. Retry.

0 comments on commit f3ac573

Please sign in to comment.