Development:Blocks/Appendix A - Revision history

Ink-ru: /* $this->version */

2010-04-21T17:16:04Z

$this->version

← Older revision		Revision as of 17:16, 21 April 2010
Line 513:		Line 513:

	Most blocks do not keep complex data of their own in the database the way that modules do, so in most cases nothing actually happens during a block version upgrade. However, the version number is displayed in the administration interface for blocks. It is good practice therefore to change your block's version number when it gains new functionality or receives important bug fixes, to enable site administrators to easily identify the exact version of the block they are working with.		Most blocks do not keep complex data of their own in the database the way that modules do, so in most cases nothing actually happens during a block version upgrade. However, the version number is displayed in the administration interface for blocks. It is good practice therefore to change your block's version number when it gains new functionality or receives important bug fixes, to enable site administrators to easily identify the exact version of the block they are working with.

			{{Top}}

	== Named constants: ==		== Named constants: ==

Ink-ru: /* _self_test() */

2010-04-21T17:15:37Z

_self_test()

← Older revision		Revision as of 17:15, 21 April 2010
Line 434:		Line 434:

	The class '''block_base''' also has a few standard member variables which its methods manipulate. These variables, the purpose of each and the type of data they are expected to hold is explained in the next section of this Appendix.		The class '''block_base''' also has a few standard member variables which its methods manipulate. These variables, the purpose of each and the type of data they are expected to hold is explained in the next section of this Appendix.

			{{Top}}

	== Class variables: ==		== Class variables: ==

Ink-ru: /* name() */

2010-04-21T17:15:14Z

name()

← Older revision		Revision as of 17:15, 21 April 2010
Line 413:		Line 413:

	This method returns the internal name of your block inside Moodle, without the '''block_''' prefix. Obtaining the name of a block object is sometimes useful because it can be used to write code that is agnostic to the actual block's name (and thus more generic and reusable). For an example of this technique, see the [[Blocks_Howto#method_config_print\| config_print]] method.		This method returns the internal name of your block inside Moodle, without the '''block_''' prefix. Obtaining the name of a block object is sometimes useful because it can be used to write code that is agnostic to the actual block's name (and thus more generic and reusable). For an example of this technique, see the [[Blocks_Howto#method_config_print\| config_print]] method.

			{{Top}}

	== Methods which you should ''not'' override and ''not'' use at all: ==		== Methods which you should ''not'' override and ''not'' use at all: ==

Ink-ru: /* specialization() */

2010-04-21T17:14:39Z

specialization()

← Older revision		Revision as of 17:14, 21 April 2010
Line 320:		Line 320:

	This method should not return anything at all.		This method should not return anything at all.

			{{Top}}

	== Methods which you should ''not'' override but may want to use: ==		== Methods which you should ''not'' override but may want to use: ==

Ink-ru: /* Appendix A: block_base Reference */

2010-04-21T16:42:49Z

Appendix A: block_base Reference

← Older revision		Revision as of 16:42, 21 April 2010
Line 1:		Line 1:
	== Appendix A: ''block_base'' Reference ==		== Appendix A: ''block_base'' Reference ==
			{{main\|Development:Blocks}}
	This Appendix will discuss the base class '''block_base''' from which all other block classes derive, and present each and every method that can be overridden by block developers in detail. Methods that should '''not''' be overridden are explicitly referred to as such. After reading this Appendix, you will have a clear understanding of every method which you should or could override to implement functionality for your block.		This Appendix will discuss the base class '''block_base''' from which all other block classes derive, and present each and every method that can be overridden by block developers in detail. Methods that should '''not''' be overridden are explicitly referred to as such. After reading this Appendix, you will have a clear understanding of every method which you should or could override to implement functionality for your block.

Ink-ru: /* BLOCK_TYPE_TEXT */

2010-04-21T15:58:16Z

BLOCK_TYPE_TEXT

← Older revision		Revision as of 15:58, 21 April 2010
Line 524:		Line 524:
	[[es:Desarrollo de bloques]]		[[es:Desarrollo de bloques]]
	[[ja:開発:ブロック/付録A]]		[[ja:開発:ブロック/付録A]]
			[[ru:Development:Blocks/Appendix_A]]

Ink-ru: /* Appendix A: block_base Reference */

2010-04-21T11:51:38Z

Appendix A: block_base Reference

← Older revision		Revision as of 11:51, 21 April 2010
Line 3:		Line 3:
	This Appendix will discuss the base class '''block_base''' from which all other block classes derive, and present each and every method that can be overridden by block developers in detail. Methods that should '''not''' be overridden are explicitly referred to as such. After reading this Appendix, you will have a clear understanding of every method which you should or could override to implement functionality for your block.		This Appendix will discuss the base class '''block_base''' from which all other block classes derive, and present each and every method that can be overridden by block developers in detail. Methods that should '''not''' be overridden are explicitly referred to as such. After reading this Appendix, you will have a clear understanding of every method which you should or could override to implement functionality for your block.

	The methods are divided into three categories: those you may use and override in your block, those that you may '''not''' override but might want to use~~, and~~ those internal methods that should '''neither''' be used '''nor''' overridden. In each category, methods are presented in alphabetical order.		The methods are divided into three categories:
			:#[[Development:Blocks/Appendix_A#Methods_you_can_freely_use_and_override:\|those you may use and override in your block]];
			:#[[Development:Blocks/Appendix_A#Methods_which_you_should_not_override_but_may_want_to_use:\|those that you may '''not''' override but might want to use]];
			:#[[Development:Blocks/Appendix_A#Methods_which_you_should_not_override_and_not_use_at_all:\|those internal methods that should '''neither''' be used '''nor''' overridden]].
			In each category, methods are presented in alphabetical order.

	== Methods you can freely use and override: ==		== Methods you can freely use and override: ==

Mits: ja link

2009-08-22T16:53:23Z

ja link

← Older revision		Revision as of 16:53, 22 August 2009
Line 519:		Line 519:

	[[es:Desarrollo de bloques]]		[[es:Desarrollo de bloques]]
			[[ja:開発:ブロック/付録A]]

Nakohdo: /* Named constants: */ moved paragraph to correct place

2009-07-02T16:57:30Z

Named constants:: moved paragraph to correct place

← Older revision		Revision as of 16:57, 2 July 2009
Line 505:		Line 505:

	== Named constants: ==		== Named constants: ==

			Appearing throughout the code related to the Blocks API, there is a number of predefined constants that are utilized to avoid the use of "magic numbers" in the code. These constants are:

	=== BLOCK_TYPE_LIST ===		=== BLOCK_TYPE_LIST ===

Nakohdo: /* $this->version */

2009-07-02T16:56:56Z

$this->version

← Older revision		Revision as of 16:56, 2 July 2009
Line 503:		Line 503:

	Most blocks do not keep complex data of their own in the database the way that modules do, so in most cases nothing actually happens during a block version upgrade. However, the version number is displayed in the administration interface for blocks. It is good practice therefore to change your block's version number when it gains new functionality or receives important bug fixes, to enable site administrators to easily identify the exact version of the block they are working with.		Most blocks do not keep complex data of their own in the database the way that modules do, so in most cases nothing actually happens during a block version upgrade. However, the version number is displayed in the administration interface for blocks. It is good practice therefore to change your block's version number when it gains new functionality or receives important bug fixes, to enable site administrators to easily identify the exact version of the block they are working with.

	~~Appearing throughout the code related to the Blocks API, there is a number of predefined constants that are utilized to avoid the use of "magic numbers" in the code. These constants are:~~

	== Named constants: ==		== Named constants: ==