Cchost/developer/concepts/Working With Data - Revision history

Fourstones: /* Alternate tables: datasource */

2008-11-15T12:53:52Z

‎Alternate tables: datasource

2008-11-15T12:53:02Z

‎Alternate tables: datasource

2008-11-13T22:30:41Z

‎Dataview Filtering

2008-11-13T22:30:12Z

‎Dataview Filtering

2008-11-13T11:10:35Z

‎Overview

2008-11-13T11:08:49Z

‎Using Dataviews in Templates

2008-11-13T11:05:31Z

‎Alternate tables: datasource

2008-11-13T11:04:52Z

‎Putting it all together

2008-11-13T10:51:36Z

‎Using Dataviews in Templates

2008-11-13T10:49:24Z

‎Using Dataviews in Templates

← Older revision		Revision as of 12:53, 15 November 2008
Line 322:		Line 322:

	for ''uploads'' means sort by the date the content was uploaded. For ''user'' it means the date the user registered with the site.		for ''uploads'' means sort by the date the content was uploaded. For ''user'' it means the date the user registered with the site.
−
−	~~api/query?~~

	=Editing Tables=		=Editing Tables=

@@ Line 308: / Line 308: @@
 *cart
 *ratings
 =Editing Tables=

@@ Line 162: / Line 162: @@
 Here's a quick psuedo walk through of what happens:
-. The dataview file defines a parametrized SQL query and some filter events.
+#The dataview file defines a parametrized SQL query and some filter events.
-. Some calls the dataview engine with a pointer to the dataview file and parameters
+#Some calls the dataview engine with a pointer to the dataview file and parameters
-. The dataview engine merges the paramters with the SQL statement and performs it.
+#The dataview engine merges the paramters with the SQL statement and performs it.
-. The dataview engine calls all the filter events passing around the result set from the SQL query.
+#The dataview engine calls all the filter events passing around the result set from the SQL query.
 The dataview file specifies which events it wants triggered in the 'e' element of the [[#Anatomy of a Dataview|return array]]. All filter events have defines associated with them that begin with ''CC_EVENT_FILTER_'' and most are defined in '''cchost_lib/cc-defines-filters.php'''.

@@ Line 157: / Line 157: @@
 ====Dataview Filtering====
 A 'filter' is a piece of code that is called with the result of the SQL query. What happens to the data in a filter is up to the filter. In technical terms a filter is a ''record munger''.
-A 'filter event' is an event that is triggered in request for a certain type of filtering to be done. Whoever responds to the After the raw rows come back from database the dataview can request any number of filter types to execute on the results. It does so by specifying them in the 'e' element of the [[#Anatomy of a Dataview|return array]]. All filter events have defines associated with them that begin with ''CC_EVENT_FILTER_'' and most are defined in '''cchost_lib/cc-defines-filters.php'''.
+A 'filter event' is an event that is triggered when a specific kind of munging is being requesting.
 Filters are not so agnostic that any filter will 'just work' on any data. For example the ''CC_EVENT_FILTER_EXTRA'' assumes that the ''cc_tbl_uploads.upload_extra'' column is in the result set. There are several cases where a filter will depend on another filter in an order dependent way. (examples to follow, sorry don't have those ready...)

@@ Line 10: / Line 10: @@
 In previous versions of ccHost querying the database tables was done in an object oriented way, building up a ''SELECT'' statement through function calls. That code still exists in the codebase and is occasionally used in older (pre-v5) code, however it was deemed too heavy on performance and a relatively needless abstraction (on top of PHP and SQL which are already high-level abstractions on top of the raw data).
-The preferred way to do querying now is either a simple straight ''SELECT'' statement (see the [[#Raw Queries|raw query]] section for one time, simple queries or [[#Dataviews|dataview]] for complex queries that are used in multiple places in the code.
+The preferred way to do querying now is either a simple straight ''SELECT'' statement (see [[#Raw Queries|raw query]]) for one time, simple queries or [[#Dataviews|dataview]] for complex queries that are used in multiple places in the code.
 Updating and inserting new records is still done through the object oriented interface.

@@ Line 85: / Line 85: @@
 ==Using Dataviews in Templates==
-All templates that are used with the Query API specify a dataview directly in the template file using the <nowiki>[meta]</nowiki> section:
+All [[Cchost/concepts/Templates|templates]] that are used with the [[Cchost/concepts/Query_Engine|Query API]] specify a dataview directly in the template file using the <nowiki>[meta]</nowiki> section:
    %%
@@ Line 93: / Line 93: @@
      [/meta]
    %%
 When you specify the template, the Query API will look at this ''meta'' section for the dataview.

@@ Line 290: / Line 290: @@
 Other than ''uploads'' the other known datasources are:
-#user
+*user
-#topics
+*topics
-#pool
+*pool
-#pool_items
+*pool_items
-#collabs
+*collabs
-#collab_users
+*collab_users
-#cart
+*cart
-#ratings
+*ratings
 =Editing Tables=

@@ Line 274: / Line 274: @@
    '''api/query?dataview=my_whiz_bang&f=xml&limit=10'''
 =Editing Tables=
 ==The CCTable Object==

@@ Line 96: / Line 96: @@
 When you specify the template, the Query API will look at this ''meta'' section for the dataview.
-If there is no meta section and then the Query API looks at the request for a ''dataview'' parameter:
+If there is no ''meta'' section, then the Query API looks back at the request for a ''dataview'' parameter:
    api/query?'''dataview=my_dataview'''&t=some_template
-If there is no ''dataview'' parameter in the request and no ''dataview'' in the Query API request then '''default''' is used ('''ccdataview/default.php'''.
+If there is no ''dataview'' parameter in the request and no ''meta'' section in the template, then the Query API uses '''ccdataview/default.php'''.
 If the template [i]does[/i] specify a dataview [i]and[/i] there is different one in the Query API request, the ''meta'' section must allow overrides using the ''dataview_param'' property with a value of 'ok':

@@ Line 94: / Line 94: @@
    %%
-When you specify the template, the Query API will look at this ''meta'' section for the dataview. If there is not meta section and no ''dataview'' in the Query API request then '''default''' is used.
+When you specify the template, the Query API will look at this ''meta'' section for the dataview.
-If the template does specify a dataview and there is another one in the Query API request, the ''meta'' section must allow overrides using the ''dataview_param'' property with a value of 'ok':
+If there is no meta section and then the Query API looks at the request for a ''dataview'' parameter:
    %%