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

Fourstones: /* Alternate tables: datasource */

2008-11-15T12:53:52Z

Alternate tables: datasource

← 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=

Fourstones: /* Alternate tables: datasource */

2008-11-15T12:53:02Z

Alternate tables: datasource

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

Fourstones: /* Dataview Filtering */

2008-11-13T22:30:41Z

Dataview Filtering

← Older revision		Revision as of 22:30, 13 November 2008
Line 162:		Line 162:

	Here's a quick psuedo walk through of what happens:		Here's a quick psuedo walk through of what happens:
	1. The dataview file defines a parametrized SQL query and some filter events.		#The dataview file defines a parametrized SQL query and some filter events.
	2. 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
	3. 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.
	4. 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'''.		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'''.

Fourstones: /* Dataview Filtering */

2008-11-13T22:30:12Z

Dataview Filtering

← Older revision		Revision as of 22:30, 13 November 2008
Line 157:		Line 157:

	====Dataview Filtering====		====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' 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.

			Here's a quick psuedo walk through of what happens:
			1. The dataview file defines a parametrized SQL query and some filter events.
			2. Some calls the dataview engine with a pointer to the dataview file and parameters
			3. The dataview engine merges the paramters with the SQL statement and performs it.
			4. 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'''.

	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...)		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...)

Fourstones: /* Overview */

2008-11-13T11:10:35Z

Overview

← Older revision		Revision as of 11:10, 13 November 2008
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).		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.		Updating and inserting new records is still done through the object oriented interface.

Fourstones: /* Using Dataviews in Templates */

2008-11-13T11:08:49Z

Using Dataviews in Templates

← Older revision		Revision as of 11:08, 13 November 2008
Line 85:		Line 85:

	==Using Dataviews in Templates==		==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]		[/meta]
	%%		%%

			('%%' is the comment block figure for [[Cchost/concepts/Templates#What.27s_a_TPL_File.3F\|TPL files]]. A PHP style <nowiki>/* */</nowiki> would work the same.)

	When you specify the template, the Query API will look at this ''meta'' section for the dataview.		When you specify the template, the Query API will look at this ''meta'' section for the dataview.

Fourstones: /* Alternate tables: datasource */

2008-11-13T11:05:31Z

Alternate tables: datasource

← Older revision		Revision as of 11:05, 13 November 2008
Line 290:		Line 290:

	Other than ''uploads'' the other known datasources are:		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=		=Editing Tables=

Fourstones: /* Putting it all together */

2008-11-13T11:04:52Z

Putting it all together

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

Fourstones: /* Using Dataviews in Templates */

2008-11-13T10:51:36Z

Using Dataviews in Templates

← Older revision		Revision as of 10:51, 13 November 2008
Line 96:		Line 96:
	When you specify the template, the Query API will look at this ''meta'' section for the dataview.		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		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':		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':

Fourstones: /* Using Dataviews in Templates */

2008-11-13T10:49:24Z

Using Dataviews in Templates

← Older revision		Revision as of 10:49, 13 November 2008
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:

			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 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':

	%%		%%